-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
WASM_WORKERS=2 documentation #21609
Comments
pthreads doesn't currently work with Regarding |
See, the name SINGLE_FILE is weird because all it does is merging the wasm into the main js. It should have been named MERGE_WASM instead. It does not create a big bundle where JS'ses got merged. So understanding it this way, both of them should work with pthread, right? I mean pthread and SINGLE_FILE still embed the wasm as base64 string as intended (even if it doesn't make a single file). |
Yes, if you define |
I think we should change the name, and leave -sSINGLE_FILE for future implementations. This has been deceiving me left and right. Btw, I think a way to embed these stuff is with an object URL, like so:
and then use the URL as normal. This will enable minifiers like closure compiler to actually understand and optimize with custom levels. This is not my idea: https://stackoverflow.com/questions/5408406/web-workers-without-a-separate-javascript-file (below accepted answer) |
…nted directly in code in https://github.com/emscripten-core/emscripten/blob/8b180923ccc1f1e05688f76bd935675d7e7c8ff1/src/library_wasm_worker.js#L130-L134 , but was not that discoverable. Closes emscripten-core#21609.
I see that
Posted a fix in #21614. WASM_WORKERS=2 build mode embeds the Wasm Worker bootstrap script into the main .html file, so a separate a.ww.html file is not needed. It would be appealing to think that we could support SINGLE_FILE+WASM_WORKERS just by making SINGLE_FILE imply WASM_WORKERS=2. But that does not quite work, because Wasm Workers cannot It would be possible to be bypassed by programmatically extracting the <script> tag from inside the single .html file, and then eval()ing that into the Worker context. If someone would like to do the gymnastics I think we could add that support. But unfortunately might defeat the purpose for many users because it would need to rely on unsafe-eval. For example, ads CDNs like to have a requirement of "single distributed file only", but they also like to have a requirement "no use of eval() or other dynamic execution", so it wouldn't enable that use case at least. |
Thoughs on this? |
I assume you are talking about making this work for pthreads? I don't see why this wouldn't work. Do you need this feature? Would you be interested in creating a PR? Would you like to open separate bug for this feature request? |
Oh wait, we already have an issue for that #17547. Assuming that is what you want, lets continue this conversation there. |
Ohk |
This is exactly what -sWASM_WORKERS=2 build mode is. It embeds the contents of the .ww.js file in an Object URL. |
This is similar to what I looked into ~5 years ago (#9796), but I abandoned it as it had a significant negative performance impact. Plus it didn't fix my initial issue. If |
Wait, if we use the same approach we will get the same issue. Also, did you find out the main step where it takes long? Is it URL.createObjectURL? |
I don't think we need to worry too much about the performance here for the initial version. Anyone who is using I suggest we start by getting something that works and then we can iterate to make it faster of folks notice a slowdown. |
Also I think its possible that the approach suggested by @RReverser in #9796 could actually be a performance and complexity win. |
What is that mode, and what does it do? Reading the code, I think it just merges the wasm worker into the main file. Also, if pthreads are allowed with SINGLE_FILE, why wouldn't wasm workers be?
The text was updated successfully, but these errors were encountered: