[WASM][MT] Failing to start inside of a web worker

[iXyles]

Description

The other day we started looking into what it'd take to enable multi threading for our wasmbrowser project that we utilize along an angular app, with the main purpose of utilizing a bunch of business logic within the browser written in C#.

We started the WASM component in a web-worker to off-load it from the "main" thread to avoid it looking UI when processing things. However, now with MT it does not seem to work - as it fails on startup during:
mono_wasm_pthread_on_pthread_attached-> currentWorkerThreadEvents.dispatchEvent(makeWorkerThreadEvent(dotnetPthreadAttached, pthread_self));
From what I have gathered it tries to do "dispatchEvent" on the "UI" thread which is also a worker.

This might not be a bug, but expected to not work - that the new MT design is meant to always be started in the web context and not in a worker context.

Reproduction Steps

wasmbrowser project worker.js

import { dotnet } from "./_framework/dotnet.js";

let modulePromise = null;

function loadWasm() {
    console.log("SharedArrayBuffer available:", typeof SharedArrayBuffer !== 'undefined', globalThis);
    console.info("Loading WASM module...");

    return dotnet
        .withConfig({
            // cacheBootResources: true // currently not supported: https://github.com/dotnet/runtime/issues/97787
        })
        .create()
        .then((net) => {
            const { getAssemblyExports, getConfig } = net;
            const config = getConfig();
            return getAssemblyExports(config.mainAssemblyName);
        })
        .then((module) => {
            console.info("WASM module loaded...");
            return module;
        });
}

function ensureLoaded() {
    return !modulePromise
        ? (modulePromise = loadWasm())
        : modulePromise;
}

function test() {
    return ensureLoaded().then((module) =>
        module.WasmClient.Test()
    );
}

// dummied down for example
addEventListener("message", (event) => {
  if (event.data.method == "test") {
      test().then((output) => {
        postMessage({ result: output });
      });
  }
});

wasmbrowser C# sample code

using System.Runtime.InteropServices.JavaScript;
using System.Threading.Tasks;

return; // Main entry point do not remove.

public partial class WasmClient
{
    [JSExport]
    public static Task<string> Test()
    {
        return Task.FromResult("Hello from C#");
    }
}

Then from JS side depending how you configure it

var worker = new Worker('./assets/wasm/worker.js', { type: 'module' });
worker.addEventListener('message', (event) => {
console.log(event); // log output from wasm
});
worker.postMessage({
  method: "test"
});

Feel free to ping me if I should setup a repo project for simplification.

Expected behavior

Expected behaviour is that the wasm project loads inside of the worker, the method is called and returns the Hello from C#. Note: This works just fine if you turn off multithreading.

Actual behavior

Regression?

Not that we know of - might be an untested territory, worth to note - this works just fine without "MT" enabled.

Known Workarounds

No response

Configuration

<PropertyGroup>
	<TargetFramework>net9.0</TargetFramework>
	<RuntimeIdentifier>browser-wasm</RuntimeIdentifier>
<OutputType>Exe</OutputType>
	<WasmMainJSPath>main.js</WasmMainJSPath><!-- points towards an empty file with console log -->
	<WasmEnableSIMD>true</WasmEnableSIMD>
	<WasmEnableThreads>true</WasmEnableThreads>
	<TrimMode>partial</TrimMode>
	<PublishTrimmed>true</PublishTrimmed>
	<WasmBuildNative>true</WasmBuildNative>
	<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
	<PublishWithAot>false</PublishWithAot>
	<WasmStripILAfterAOT>false</WasmStripILAfterAOT>
	<WasmAppDir>../webapp/src/assets/wasm</WasmAppDir><!-- adjust accordingly -->
</PropertyGroup>

Build project with dotnet publish and the files needed will be copied if WasmAppDir is configured correctly.

Other information

mono_wasm_pthread_on_pthread_attached being called for the "UI" aka main thread even though the comment says it should not. But when the main thread is a worker it fails some pre-check (is the initial guess)

[dotnet-policy-service]

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

[maraf]

cc @pavelsavara

[pavelsavara]

There is lot of postMessage drama in MT and I guess that may be the problem.
Or maybe the way how we detect "main" thread, expecting it to be "UI" thread.

It could be fixable, but currently not a priority for us.

[iXyles]

Do I understand it correctly that if we wish to try utilize MT for now we have to move back to none worker host, as it is not the focus to get that working but rather primarily adapt it for blazor-webassembly.

Since this is a different kind of use-case situation which is not prio to support - I do wonder if there is a way then to force the "main" thread to move the actual work to a worker, in simple terms changing the C# layer to push it to the worker

Would this example work, or would something more be required?

[JSExport]
public static Task<string> Test() // or is it sufficient that this is `Task` 
{
    return ExecuteOnWorker(() => TestImpl());
}

static Task<T> ExecuteOnWorker<T>(Func<Task<T>> workFunction)
{
    // Assuming this is will cause the `workFunction` to run on a worker
    return Task.Run(async () => await workFunction());
}

static async Task<string> TestImpl()
{
    // Simulate some async work
    await Task.Delay(100); // Example delay
    return "Hello from C#";
}

[pavelsavara]

This is the MT design does it help ?

[iXyles]

Seems so, my understanding from the design & comments regarding net9 section is that as long the JSExports methods in C# are Task<T> that we call from the web app will be off-loaded to a worker, and then return to the deputy thread (in this instance our web app) to continue working with the output data.

Will have to do a small POC to verify that my assumption is correct, and see if fits/work for our cases.
I'd however say that the given example scenario would be nice to see working, but I do understand that it will not be prioritized at this point in time.