SINGLE_FILE and pthread incompatibility

[jason-variadiclabs]

According to #12833 (comment) which says the following:

SINGLE_FILE=1 is not supported with Wasm Workers (like it is not supported with pthreads)

I'm unable to find other specific documentation for pthreads not supporting SINGLE_FILE, but locally I can confirm that removing SINGLE_FILE does indeed fix the threading issue I'm running into (where the thread does not get executed with detach).

What is the specific reason(s) that SINGLE_FILE does not work with pthreads? From what I understand about SINGLE_FILE, it adds the contents of the .js and .wasm files (as a Base64 string) into the HTML file as opposed to reading the wasm contents via locateFile - clearly there is something else that I'm missing.

[kripken]

I think we'd need to find a solution for the *.worker.js file which is normally separate. I guess it could be bundled as a string and evalled, but using eval does not work everywhere. There might be a better approach without eval, that's worth thinking about.

[Username404-59]

I think bundling the worker in the main .js file would also fix #16706

[msqr1]

I can definitely make a PR for this with #21609 (comment)

[juj]

Here is how the build modes currently produce output files:

Mode	out.html	out.js	out.wasm	out.ww.js	out.worker.js
No flags	X	X	X
-sWASM_WORKERS=1	X	X	X	X
-sWASM_WORKERS=2	X	X	X	Not generated. Gets embedded as an Object URL into out.js
-pthread	X	X	X		X
-pthread -sWASM_WORKERS=1	X	X	X	X	X
-sSINGLE_FILE	X	Not generated, gets embedded as a <script> tag in .html file	Not generated, gets embedded to .html file as base64 (or as UTF-8 after #21478 lands)

Issues arise if we try to combine -sSINGLE_FILE with either -pthread or -sWASM_WORKERS, because with -sSINGLE_FILE we do not generate any .js files to the output. All the JS code now lives in a <script> tag inside the HTML file, there is nothing to importScripts() easily.

This means that the spawned Worker would need to get all of the generated JS code into its scope in some other way.

If we resort to allowing unsafe-eval, then we could support a -sSINGLE_FILE -sWASM_WORKERS=2 build mode by writing a function that would XHR in out.html as text, and then it would use regex/string operations to snip out the contents inside the main <script> tag, and then concatenate that JS code into an Object URL, and load it into the Worker in a fashion similar to the existing -sWASM_WORKERS=2 bootstrap code works.

Same treatise could theoretically be given to -sSINGLE_FILE -pthread build mode, although that one will be more difficult, because the worker.js bootstrap script is much much larger than the Wasm Workers bootstrap script is.

If someone wants to experiment with such build modes, I think we would be happy to land that capability. Though it is good to research bit into that unsafe-eval CSP rule to ensure that requiring that CSP policy would then not be a dealbreaker in your deployment. (I know that e.g. in ads CDNs deployment, who are a user of -sSINGLE_FILE, typically do not allow unsafe-eval)

[sbc100]

Its not true that -sSINGLE_FILE never generates a .js file. By default a JS file is generated which embeds that wasm.

The only case in which we don't generate a .js when using -sSINGLE_FILE is if the user explicitly ask for a .html file output (or uses --oformat=html).

[sbc100]

Perhaps we could make the error more targeted:

if settings.SINGLE_FILE and settings.PTHREAD and options.oformat == OFormat.HTML:
   exit_with_error("-pthread is not compatible with single file html output");