Inline pthread worker.js file into the main output file

[sbc100]

This method has many advantages over the previous method of generating a separate file:

• Avoids separate output file simplifying deployment.
• Avoids confusing laying of global scopes
• Avoids exporting symbols on the Module simply for visibility within the worker file.
• Avoids code duplication
• Avoids the needs to importScripts call, and the node polyfill for this.
• Allows optimizers such as closure and JSDCE to operate on the combined code.
• -sSINGLE_FILE now works with pthreads
• Fewer network requests
• No need for locateFile logic to run on the worker to find the worker.js

The test_pthread_custom_pthread_main_url test was completely removed
since it was testing how worker.js was located and worker.js no longer
exists.

Fixes: #9796

[msqr1]

Would you consider doing this for wasm workers and audio worklets? Also, if this has many advantages, I would suggest making this the default, while keeping option to NOT embed the wasm file, for reduced size, module caching and stuff.

[sbc100]

Would you consider doing this for wasm workers and audio worklets? Also, if this has many advantages, I would suggest making this the default, while keeping option to NOT embed the wasm file, for reduced size, module caching and stuff.

Absolutely! One step a time though. Getting pthreads done first because it probably most used (and likely the hardest to get working) so a good proof of concept.

[msqr1]

What about this being default and wasm file embedding? What do you think? We can make another setting called EMBED_WASM

[sbc100]

What about this being default and wasm file embedding? What do you think? We can make another setting called EMBED_WASM

My plan is to make this not only the default, but the only option. I don't see any reason at this point to keep the old method around.

Don't we already have -sSINGLE_FILE to controle the Wasm embedding? I don't see that ever being the default BTW because it comes with several downsides, the most major of which it prevent streaming compilation and caching the wasm module.

[msqr1]

SINGLE_FILE seems to mean embed everything into one file, not just the wasm, I think we should have another name for embedding or separate the wasm since this can be quite misleading

[sbc100]

SINGLE_FILE seems to mean embed everything into one file, not just the wasm, I think we should have another name for embedding or separate the wasm since this can be quite misleading

But if we remove the separate worker files, what other file are there? Another way of putting it: What files would you not want to embed when you use -sSINGLE_FILE?

[msqr1]

You're right, my mistake. But should we just rename the settings anyway? I'm really excited for this to land ngl

[sbc100]

You're right, my mistake. But should we just rename the settings anyway? I'm really excited for this to land ngl

Doesn't SINGLE_FILE make sense? IIUC it is normally by for folks who don't want to worry about hosting multiple files, and want do distribute just one.. so that name seem to match the purpose. What about it do you think is confusing?

[msqr1]

We should use a global switch statement for this? For simplicity I suggest just doing globalThis.constructor.name == "xxxGlobalScope", not using the ENVIRONMENT_IS_XXX

[curiousdannii]

Rather than using a query string (which may complicate caching), can you use the name option?

Only potential issue I can see is that it's not supported in Android Webview, but I'm not sure if that's a supported browser.

[sbc100]

Rather than using a query string (which may complicate caching), can you use the name option?

Sure we can try that. Can you explain what you mean by "may complicate caching"?

Only potential issue I can see is that it's not supported in Android Webview, but I'm not sure if that's a supported browser.

[curiousdannii]

Just that many caches may distinguish query strings. It may not be added to service worker caches either. I was thinking of a case where you add all the files in a service worker for offline use, but then it fails because of the query string.

If someone was using a service worker they could work around that though. But it might be more predictable to avoid it possible. I don't know that the name property is a viable alternative however.

[sbc100]

Just that many caches may distinguish query strings. It may not be added to service worker caches either. I was thinking of a case where you add all the files in a service worker for offline use, but then it fails because of the query string.

If someone was using a service worker they could work around that though. But it might be more predictable to avoid it possible. I don't know that the name property is a viable alternative however.

Are you saying that adding the query string would mean that the file would not cached at all, or that maybe we would end up with two seperate cache entries (one for the main.js and another for the main.js?phthread=1)? I like the idea of using name since we do control that.