[browser][mt] Provide API to start the web workers later

[lambdageek]

By default we start the web worker pool that will host pthreads at app startup and wait for each worker to finish loading.
Compared to single threaded apps, this increased page load times.

Starting the worker pool at startup was reasonable because we just used Emscripten's worker startup code. But eventually we ended up overriding that startup sequence with our own code so that we could set up resources on the workers, transfer the MonoConfig, etc.

The upshot is that since we control the worker creation now, we don't have to do it when Emscripten used to. We can give app frameworks more control.

For example, we can provide a mechanism for the application (or the app framework) to start up the threadpool at a later time once the initial page is done loading. We could have an API like:

   namespace System.Runtime.InteropServices.JavaScript;

   public class Threading {
      // returns number of workers that were actually started
      public static Task<int> CreatePThreadWebWorkerPool (int numWorkers);
   }

And the app framework would call await Threading.CreatePThreadWebWorkerPool(numWorkers: AppConfig.RequestedPoolSize) at an appropriate time once the UI has been rendered.

We could also consider Task<bool> TryAddWebWorker() API for growing the worker pool.

The constraints from the runtime/Emsciprten/the web platform:

• only callable on the main thread (although we could proxy the call over to the main thread in the runtime).
• is async (we need to return to the JS event loop to send some messages back and forth to the fresh worker)
• may fail if we hit the browser's limit on the number of workers per page

[ghost]

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

Issue Details

---

By default we start the web worker pool that will host pthreads at app startup and wait for each worker to finish loading.
Compared to single threaded apps, this increased page load times.

Starting the worker pool at startup was reasonable because we just used Emscripten's worker startup code. But eventually we ended up overriding that startup sequence with our own code so that we could set up resources on the workers, transfer the MonoConfig, etc.

The upshot is that since we control the worker creation now, we don't have to do it when Emscripten used to. We can give app frameworks more control.

For example, we can provide a mechanism for the application (or the app framework) to start up the threadpool at a later time once the initial page is done loading. We could have an API like:

   namespace System.Runtime.InteropServices.JavaScript;

   public class Threading {
      // returns number of workers that were actually started
      public static Task<int> CreatePThreadWebWorkerPool (int numWorkers);
   }

And the app framework would call await Threading.CreatePThreadWebWorkerPool(numWorkers: AppConfig.RequestedPoolSize) at an appropriate time once the UI has been rendered.

We could also consider Task<bool> TryAddWebWorker() API for growing the worker pool.

The constraints from the runtime/Emsciprten/the web platform:

• only callable on the main thread (although we could proxy the call over to the main thread in the runtime).
• is async (we need to return to the JS event loop to send some messages back and forth to the fresh worker)
• may fail if we hit the browser's limit on the number of workers per page

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-Threading-mono
Milestone:	8.0.0

[pavelsavara]

with deputy design this is no longer issue. We use all normal C# APIs to create threads