JSPI integration

Start with the JSPI integration description, especially WebAssembly.Suspending, WebAssembly.promising, Promise.then, the imported JSPI event tag, and resume_throw. Determine whether the JSPI event should be importable and specify the behavior and use cases clearly enough for a follow-up proposal or implementation.

JSPI can be seen (and potentially re-specified) as using core stack switching. Specifically, the WebAssembly.Suspending import wrappers can be seen as suspending with a JSPI event tag with type [externref] -> [externref]. The externref sent on the suspension is the Promise whose resolution will resume the suspended WebAssembly. The JSPI event is handled in the WebAssembly.promising export wrapper, which calls Promise.then to arrange for the continuation to be resumed when the promise is resolved. When the continuation is resumed, the WebAssembly.Suspending wrapper has to do some additional work to unbox the values from the resolved Promise and return them back into Wasm.

This formulation of JSPI raises the questions of what would happen if the JSPI event tag were made available to be imported into user Wasm modules and whether this would be useful to allow.

Suspending with the imported JSPI tag and accompanying externref holding a Promise would be equivalent to calling an imported JSPI-wrapped JS function that simply takes and returns that Promise, but without the overhead of actually calling an import. If the suspension reaches a WebAssembly.promising export wrapper, it would chain the resumption of the resulting continuation onto the Promise just like it would for a "normal" JSPI suspension.

Handling an event with the JSPI tag would give you an externref holding a Promise and a continuation. At that point you could call out to JS to manually chain the continuation onto the Promise like the normal WebAssembly.promising export wrapper does, or alternatively you could do anything else. For example, you might chain a callback onto the Promise that does not immediately resume the continuation, but rather puts it onto some application-managed scheduling queue. Or maybe you could arrange for the continuation to be canceled with resume_throw if the Promise is not resolved within a certain amount of time. The possibilities are endless, and more importantly, they cannot be fully replicated just by JSPI and import calls.

In conclusion, I think that yes, it would be reasonable and useful to make the JSPI event importable. (But of course we can always add this as a follow-up once demand for it materializes.)