WASM_WORKERS=2 documentation

[msqr1]

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?

[sbc100]

pthreads doesn't currently work with -sSINGLE_FILE .. even though you don't see a compiler error, it still creates the worker as a seperate file, doesn't it?

Regarding WASM_WORKERS=2.. it doesn't look like this is well documented. I don't actually know what that wasn't just -sWASM_WORKERS + -sSINGLE_FILE. @juj do you remember?

[msqr1]

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).

[sbc100]

Yes, if you define SINGLE_FILE as simply meaning embed-wasm-in-js. But I think a lot of SINGLE_FILE users actually do want just a single file so that they don't need to host more than one file, or even run a server at all. So I think logically it would make sense for SINGLE_FILE to imply that the worker.js is also embedded. But I don't think we have a way to do that for pthreads today.

[msqr1]

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:

var workerURL = URL.createObjectURL(new Blob(['(',
  (() => {
    // Some worker code
  }).toString(),
')()'], {type : "text/javascript"}))

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)

[juj]

pthreads doesn't currently work with -sSINGLE_FILE .. even though you don't see a compiler error, it still creates the worker as a seperate file, doesn't it?

I see that emcc test\hello_world.c -pthread -sSINGLE_FILE would work, and run correctly, since it doesn't attempt to spawn any threads. But if attempting to launch threads, emcc test\pthread\hello_thread.c -pthread -sSINGLE_FILE, then execution fails. Posted #21617 to manage this incompatibility.

Regarding WASM_WORKERS=2.. it doesn't look like this is well documented. I don't actually know what that wasn't just -sWASM_WORKERS + -sSINGLE_FILE. @juj do you remember?

Posted a fix in https://github.com/emscripten-core/emscripten/pull/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 importScripts() the generated JS file since it then resides inside the main .html file.

It would be possible to be bypassed by programmatically extracting the Githubissues.

Githubissues is a development platform for aggregating issues.