Add MAIN_THREAD_EM_ASM_PROMISE_AWAIT by hedwigz · Pull Request #23043 · emscripten-core/emscripten

hedwigz · 2024-12-01T21:41:01Z

Introduce a new macro MAIN_THREAD_EM_ASM_PROMISE_AWAIT which is used to write JavaScript code that returns a promise and block the C code from progressing until the promise is resolved (or errors).

int main() {
  printf("1st print\n");
  // This call will block until the internal promise resolves (at least 1 second in this case) 
  MAIN_THREAD_EM_ASM_PROMISE_AWAIT({
    out('2nd print');
    // do some async operation that involves the main thread
    return new Promise((resolve,reject) => {
      setTimeout(() => {
        out('3rd print');
        resolve();
      }, 1000);
    });
  });
  printf("4th print\n");
  return 0;
}

The motivation for this was discussed before
We have multiple web workers, each of them calls javascript code which is async and has to be ran on the main thread and need to wait for the promise to be resolved.
I am open for suggestions on how to add this more elegantly

hedwigz · 2024-12-06T15:45:50Z

@sbc100 Thanks for taking the time to review this. I addressed all of your comments and did the following:

Added an error if the macro is called from main thread (and added test)
Added support for receiving a return integer from the macro
Added documentation
LMK what you think :)

hedwigz · 2024-12-13T05:56:11Z

@sbc100 ping 🤞

sbc100

@tlively would you mind taking a look, since this contains changes to proxying.c

hedwigz · 2024-12-14T18:44:14Z

@sbc100 @tlively 🙏 I really appreciate the thorough review and comments!
I addressed all of your comments and I think the code looks way better now.

tlively

Great, this looks a lot simpler overall, even though I agree that it's a little awkward to get the ctx into the right place. Thanks!

hedwigz · 2024-12-18T20:22:40Z

Great, this looks a lot simpler overall, even though I agree that it's a little awkward to get the ctx into the right place. Thanks!

I am sorry I completely messed up git while trying to rebase.

hedwigz · 2024-12-18T20:37:28Z

@tlively any tips for passing all the CI tests?

tlively · 2024-12-18T21:47:24Z

proxying.c looks good to me.

It looks like the flake8 bot is failing because of a formatting issue. The other CI bots might be aborting early because of that issue. Merging in main to pick up any unrelated fixes could also help.

sbc100 · 2024-12-18T22:07:21Z

The fact that flake8 is being included at all in CI makes me think that perhaps you are not up-to-date on your branch? The flake8 step was replaced with a step call ruff few days back.

sbc100 · 2024-12-18T22:07:49Z

Can you try rebase onto to merging with the latest changes on main?

sbc100 · 2025-04-03T15:25:36Z

Any updates or blockers here? I'd like to see this land as well, we're also using workers that need to sync await some main thread code.

Hey @hybridherbst , glad to see more interest in this. The current blocker is that some wasm64 test fail. I was struggling making the test run on my machine due to the need in d8/node24

d8 you can get usinfg the jsvu tool.

node-canary you can you get from https://nodejs.org/download/v8-canary/

hedwigz · 2025-04-04T10:56:00Z

@sbc100 Thanks! I'll give it a go

hedwigz · 2025-04-07T03:52:24Z

@tlively @sbc100 All tests are now green :)

hedwigz · 2025-04-13T06:49:50Z

@sbc100 @tlively ping 😎

sbc100 · 2025-05-27T19:09:49Z

Thanks for continuing to work on this.

Apologies for the review process taking so long. I had no imagined this being such an invasive change (i.e.changing the code proxying functions).

hedwigz · 2025-06-08T07:48:08Z

@sbc100 Thanks, I appreciate the continued work on this. I didn't have much time recently to cater to this PR. I'll hopefully get back to it soon.

sbc100 · 2026-03-05T00:58:28Z

Sorry for the long delay on this.

I've since landed a JS library feature that is kind of like this one: #26000. So I think i now have a much better understanding of the use case.

Would you have time to rebase this and we can see about landing it?

Co-authored-by: Cursor <cursoragent@cursor.com>

hedwigz · 2026-09-14T11:49:07Z

@sbc100 Hey, I rebased it and addressed all of your comments

sbc100 · 2026-09-16T21:41:56Z

@guybedford WDYT of this extra macro/tool?

sbc100 · 2026-09-16T21:46:25Z

-      rtn.then((rtn) => __emscripten_run_js_on_main_thread_done(ctx, ctxArgs, rtn));
+      rtn.then(
+        (rtn) => __emscripten_run_js_on_main_thread_done(ctx, ctxArgs, rtn),
+        () => __emscripten_run_js_on_main_thread_done(ctx, ctxArgs, 0),


Does this mean we always return zero on promise rejection? Is this needed? What is we have a function that uses a zero return to mean something else?

Do you need this feature? Maybe we should leave it out for the initial version?

sbc100 · 2026-09-16T21:46:58Z

+Inside MAIN_THREAD_EM_ASM_AWAIT: 42 3.5
+Inside asyncOp
+After MAIN_THREAD_EM_ASM_AWAIT
+result: 2


missing newline here

sbc100 · 2026-09-16T21:49:46Z

+
+int main() {
+  emscripten_out("Before MAIN_THREAD_EM_ASM_AWAIT");
+  int res = MAIN_THREAD_EM_ASM_AWAIT({


Might it be nice if we could use await inside these functions?

i.e. should we mark these function snippets as async on the JS side?

sbc100 · 2026-09-16T21:51:18Z

+#if ASSERTIONS
+    assert(ENVIRONMENT_IS_PTHREAD, 'emscripten_asm_const_int_await_on_main_thread is not available on the main thread');
+#endif
+    return runMainThreadEmAsm(emAsmAddr, sigPtr, argbuf, 2);


I wonder if these is some way we can avoid the magic number here?

How about {{{ PROXY_SYNC_ASYNC }}}?

sbc100 reviewed Dec 3, 2024

View reviewed changes

Comment thread src/library.js Outdated

Comment thread test/test_core.py Outdated

Comment thread test/core/test_main_thread_async_em_asm_promise_await.cpp Outdated

Comment thread src/library_pthread.js Outdated

hedwigz requested a review from sbc100 December 6, 2024 15:46