[wasm-mt] Publish dotnet.worker.js

[lambdageek]

The WasmApp.targets should place dotnet.worker.js next to dotnet.js

There may also be an issue with Blazor dotnet publish doing likewise.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The WasmApp.targets should place dotnet.worker.js next to dotnet.js

There may also be an issue with Blazor dotnet publish doing likewise.

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, untriaged
Milestone:	-

[pavelsavara]

We probably need a way how to customize it.

• so that it's compatible with ES6 when loading the dotnet.js
• so that it's compatible our module exports, which are not Module object
• so that it's CSP compliant, no eval
• so that it doesn't use require in NodeJs + ES6

[lewing]

I'd love to have consistent naming pattern for all the workers and we need to make sure that the blazor publish step includes them in the output.

cc @radical @javiercn

[radical]

@javiercn if we populate a msbuild item with the files to deploy (not exhaustive), then would you be able to use that to ensure that they get deployed wherever needed?

[javiercn]

@radical yes. that would help.

@lewing I set up some time with Ankit to go through the details.

[lewing]

It is worth reading through #48016 as well

[lambdageek]

I'd love to have consistent naming pattern for all the workers and we need to make sure that the blazor publish step includes them in the output.

renaming dotnet.worker.js is possible, if that's what we want to do - it looks like Emscripten will go through locateFile to get the URL to load. (going the other way - when dotnet.worker.js imports dotnet.js - it goes through the mainUrlOrBlob property on the module - which we do set up : anyModule.mainScriptUrlOrBlob = replacements.scriptUrl; // this is needed by worker threads

tl;dr if we want the published app to use different/consistent naming for worker JS files, we can do that.

[lambdageek]

We're going to need to install a replacement for PThread.allocateUnusedWorker (here's the default one):

 allocateUnusedWorker: function() {
  if (!Module["locateFile"]) {
   PThread.unusedWorkers.push(new Worker(new URL("dotnet.worker.js", import.meta.url)));
   return;
  }
  var pthreadMainJs = locateFile("dotnet.worker.js");
  PThread.unusedWorkers.push(new Worker(pthreadMainJs));
 },

We should use the new js-module-threads asset type and callresolve_module_url to get the worker URL. see #73073 (comment)

---

Note that emscripten pre-allocates at startup by calling

PThread.init ();

in its giant global initialization (before it calls the Module["preInit"] callbacks. So we would need to also replace PThread.init and make it async in order to wait until the asset machinery is setup.

[lambdageek]

Replacing Module["PThread"]["init"] is not really feasible - emscripten calls PThread.init very early - before our replacement code runs.

On the bright side PThread.init just calls PThread.initMainThread or PThread.initWorker. initWorker is fine as is. initMainThread doesn't do anything other than call allocateUnusedWorker based on the size of PTHREAD_POOL_SIZE.

So we could:

1. set -s PTHREAD_POOL_SIZE=0 in wasm.proj
2. make our own pthreadPreallocatePool function that we can call during startup, based on some MONO_PTHREAD_POOL_SIZE property that we define.
3. replace allocateUnusedWorker with one that uses resolve_asset_path (from assets.ts). the replacement is too late for PThread.init, but that doesn't matter since it won't be allocating any workers.

I'm going to give it a go

[pavelsavara]

The way how to resolve the asset is now merged

        const asset = resolve_asset_path("js-module-threads");
        mono_assert(asset && asset.resolvedUrl, "Can't find js-module-threads");
        const worker = new Worker(asset.resolvedUrl);

You will also need to add it to the mono-config.json via src\tasks\WasmAppBuilder\WasmAppBuilder.cs

config.Assets.Add(new ThreadsWorkerEntry ("dotnet.worker.js") );

[pavelsavara]

This is what SDK needs to do https://github.com/dotnet/sdk/pull/26966/files

[lambdageek]

yep, I have it basically working. PR soon