Similarity to Emscripten's proxying API

[tlively]

The pattern of sending asynchronous work to another thread and synchronously waiting for it to complete is well supported by emscripten_proxy_sync_with_ctx from Emscripten's proxying.h library. The main idea appears to be the same as the POC in this repo. That API and the others in proxying.h are implemented on top of low-level task queues (header, implementation) that ultimately use Atomics.waitAsync and __builtin_wasm_memory_atomic_notify if possible or fall back to postMessage if necessary to send work to other threads.

There's also an Emscripten contributor currently working on adding an MAIN_THREAD_EM_ASM_PROMISE_AWAIT macro built on top of the proxying.h APIs to make synchronously waiting for some promise to be resolved on the main thread very easy.

Despite there being very mature support for this proxying pattern today, it does not solve all the problems JSPI solves and it introduces new problems of its own.

• Deploying threaded Wasm applications is still a pain due to COOP and COEP requirements, making it a non-starter for many users, especially library developers that have no control over the serving infrastructure that will eventually be used. JSPI does not have these onerous deployment requirements.
• JS run on a dedicated worker thread cannot interact with the rest of the JS in an application. This may be fine for isolated JS used only to bridge C/C++ libraries to Web APIs, but this is a problem when the Wasm must interact with nontrivial application state held in JS. JSPI does not have this problem because all code is run on the same thread.
  • Moving application JS state to the worker thread is generally a non-starter.
  • Moving Wasm execution to the worker thread and proxying asynchronous work back to the main thread is generally more feasible, but introduces complexity and overhead when calling into Wasm.
• When running application logic on the main thread, synchronously waiting for another thread to complete a long-running asynchronous operation may introduce jank or even prompt an unresponsive tab dialogue. In contrast, JSPI presents the same observed behavior to the application without ever blocking the main thread.

[kmiller68]

As I've discussed with Francis, our main concern is not with JSPI by itself it's that we're unconvinced that side stacks are the way core-stack switching should go (happy to have a chat about this via VC or at the next stacks meeting). If we decide that side stacks are not the way we want to go then we've locked ourselves into supporting side stacks forever by shipping JSPI anyway. Given that, it's expected that this library wouldn't solve every single use case that JSPI supports. As if we end up concluding we need side stacks we're happy to ship JSPI. Some other thoughts/replies, which I think are also covered in the README.md:

Deploying threaded Wasm applications is still a pain due to COOP and COEP requirements, making it a non-starter for many users, especially library developers that have no control over the serving infrastructure that will eventually be used. JSPI does not have these onerous deployment requirements.

Agreed but IMO the way we should solve that is a syncPostMessage, which would be far less performant but would still be functional. Or a more sophisticated handshaking so if every web origin in a process agrees they're willing to share memory (aka not have secrets) they can, which again, I think we should do.

JS run on a dedicated worker thread cannot interact with the rest of the JS in an application. This may be fine for isolated JS used only to bridge C/C++ libraries to Web APIs, but this is a problem when the Wasm must interact with nontrivial application state held in JS. JSPI does not have this problem because all code is run on the same thread.

I think you misunderstood the code. JS is always run on the original thread here. I suppose you could explicitly opt to avoid the bridging if you want but I would assume that wouldn't be the default.

Moving application JS state to the worker thread is generally a non-starter.

Agreed.

Moving Wasm execution to the worker thread and proxying asynchronous work back to the main thread is generally more feasible, but introduces complexity and overhead when calling into Wasm.

I think you'll need to expand on exactly what this extra complexity is as this is exactly what I'm doing here. It seems like that complexity could be handled by Emscripten or toolchains, which while not ideal still isn't a deal breaker.

When running application logic on the main thread, synchronously waiting for another thread to complete a long-running asynchronous operation may introduce jank or even prompt an unresponsive tab dialogue. In contrast, JSPI presents the same observed behavior to the application without ever blocking the main thread.

I didn't see any missed frames in my MVP but I don't see why JSPI would be better. Why would JSPI not block the main thread if the main thread is doing a bunch of work?

This library only blocks the main thread for small spin loops or when actively running JS code driven by the main thread anyway (thus would be "blocked" in JSPI too). If anything for most use cases less work is done on the main thread in this library vs JSPI. Which I suppose could be a problem when switching from this to JSPI in the future lol.