-
Notifications
You must be signed in to change notification settings - Fork 30
Enable libdispatch or provide stubs for it #647
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
Comments
Building the upstream libdispatch code is currently blocked by #658. |
Is there a way to build libdispatch on top of the Wasm Thread or web worker? |
The big problem here is that WebAssembly threads are available only in a few browsers such as Chrome, and only under a flag. The threads proposal is still in flux, so no matter what we do now, would probably need to change later. And with web workers, you still need some syncronization primitives, which requires shared memory between WebAssembly modules. The only way to do that currently is with
|
Thanks for the answer. So the only hope is to wait for WASM Thread |
Basically yes. I think the availability of I'm following the threads proposal and surely it's best to start thinking about it now. But another reasoning here is that we have very limited resources on the toolchain side of things. We need to carefully pick high priority things and complete those quickly, primarily to drive the SwiftWasm ecosystem adoption. I personally wouldn't have the capacity to look into both the web worker emulation and the true threads support. If you're willing to drive implementation efforts for either of those, that would very greatly appreciated 🙏 By the way, with regards to capitalization it's "Wasm" or "wasm", but never "WASM", because it is not an acronym. 🙂 We also follow the capitalization convention established by RustWasm. |
Absence of a working
Dispatch
module blocks #592, #597 and #646 as all of those depend onDispatch
.The text was updated successfully, but these errors were encountered: