-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
async / promise support #1171
Comments
Any support of JS promises would have to be part of the JS host bindings proposal. But I'm afraid it cannot possibly work like your example suggests, since that would require C itself to understand async execution and suspension, which it doesn't. Also, there is nothing async in your example, it just creates a promise, so the equivalent code wouldn't even suspend in JS itself, but just produce a string like |
Well, the value is not available until the eventloop processes the promise.
That's incorrect. There are various coroutine implementations for C. https://llvm.org/docs/Coroutines.html And as an addendum to C++17 there is the coroutine-ts that has been implemented since clang-5.0. |
Implementations of coroutines in C do not magically interoperate with JavaScript's event loop. Also, they usually rely on implementation-specific behaviour. To reliably and portably implement something like coroutines or async you'd need a form of delimited continuations in the language. The closest C has to offer is longjmp, which isn't enough and cannot currently be implemented in Wasm itself (with Emscripten, longjmp is implemented in JS with JS exceptions). Wasm cannot currently express suspension, although there are plans to add something along these lines eventually. C++ coroutines aren't standard yet and cannot be handled by Emscripten AFAICT. |
I see where you are coming from.
Why do you think it is required for C to understand async execution? What's the technical difficulty to suspend the wasm execution engine until the promise is resolved? I understand that wasm is supposed to be ahead-of-time compiled to x86 but it does not mean you have no control over the flow of execution. I guess this issue should be filed in the host-bindings repo... |
I think you misunderstand the computational model of the web. JavaScript isn't multi-threaded, so suspending a computation would halt the engine, and in fact the entire renderer hosting it. The page would freeze and no other code could run (other than separate workers). You'd need a way of reifying and later restoring continuations to make suspension fly, which is not something engines currently can do. |
related: #720 |
Exactly, wasm should be run inside workers as they both created for computation tasks rather than dealing with UI. |
Many JavaScript libraries are async and I have not seen that WebAssembly supports promises yet.
In order to easily write performant applications that leverage the JS ecosystem I'd suggest to add support of promises in imported functions.
For instance this should work:
The text was updated successfully, but these errors were encountered: