Skip to content

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

Open
MaxDesiatov opened this issue Apr 12, 2020 · 5 comments
Open

Enable libdispatch or provide stubs for it #647

MaxDesiatov opened this issue Apr 12, 2020 · 5 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@MaxDesiatov
Copy link

Absence of a working Dispatch module blocks #592, #597 and #646 as all of those depend on Dispatch.

@MaxDesiatov MaxDesiatov added bug Something isn't working help wanted Extra attention is needed in progress The issue is currently being worked on labels Apr 12, 2020
@MaxDesiatov MaxDesiatov self-assigned this Apr 12, 2020
@MaxDesiatov MaxDesiatov removed the in progress The issue is currently being worked on label Apr 12, 2020
@MaxDesiatov MaxDesiatov removed their assignment Apr 12, 2020
@MaxDesiatov
Copy link
Author

Building the upstream libdispatch code is currently blocked by #658.

@lin7sh
Copy link

lin7sh commented Jun 20, 2020

Is there a way to build libdispatch on top of the Wasm Thread or web worker?

@MaxDesiatov
Copy link
Author

MaxDesiatov commented Jun 20, 2020

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 SharedArrayBuffer which is slow as it requires bridging to JavaScript, and is also disabled in most browsers:

Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome re-enabled it in v67 on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.

@lin7sh
Copy link

lin7sh commented Jun 20, 2020

Thanks for the answer. So the only hope is to wait for WASM Thread

@MaxDesiatov
Copy link
Author

MaxDesiatov commented Jun 20, 2020

Basically yes. I think the availability of SharedArrayBuffer in all browsers would allow us to emulate threads with web workers, but I wouldn't be surprised if it doesn't become widely available earlier than WebAssembly threads. Then what's the point of doing emulation for a single browser (Chrome in this case)?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants