Multithreaded app in React does not start

[sophonet]

Earlier, I have successfully integrated a single-threaded emscripten-based WASM app in a React application (invoking the WASM app(Module) from a useEffect() call). Rendering works on the canvas as expected.

After switching on multi-threading (-pthread, PROXY_TO_PTHREAD, OFFSCREENCANVAS_SUPPORT) for accelerated rendering, the app still starts when viewing it via a hand-crafted index.html that includes app.js, defines the Module and its canvas and calls the app(Module)... and the canvas gets filled as expected.

However with multi-threading the exact same code does not work in a React application in a startup useEffect() call results in an error event "Pthread 0x01519128 sent an error! undefined:undefined: undefined" triggered in loadWasmModuleToWorker. Interestingly, when compiling the app even with a minimum thread pool size of two "SHELL:-s PTHREAD_POOL_SIZE=2", the app does not start at all: "waiting for dependencies, dependencies: workers" is repeated every couple of seconds in the console.

Any hints how to solve this issue or ideas how this happens? It seems strange to me since React does not do anything with threads.

[kripken]

waiting for dependencies, dependencies: workers suggests it is failing to create the Workers it needs for pthreads support. If there are no other errors in the console, perhaps try building with -sASSERTIONS. Otherwise, I would try to run the app outside of React to see it works.

[sophonet]

I have the exact same question: What is react changing? I had hoped that the example I have prepared is tiny enough for debugging, I have set the react build process to yield a js file which is still verbose for debugging, so it should contain the emscripten js output + the react js output, which I don’t think can be made much tinyer… the react app just contains the same calls as the vanilla index.html does- and the VTK rendering stuff in in the wasm does not get involved much.

Any hint how I can continue debugging with the example to nail down the problem?

[kripken]

I had hoped that the example I have prepared is tiny enough for debugging

I don't have Docker installed so I can't run it. Ideally the testcase would be just a js+wasm file, and very small. But as this requires react to see the problem, maybe react is large? if so then a minimal testcase might be impossible.

You might want to try to follow logging from the emscripten code. If you build with -sPTHREADS_DEBUG it will log out a lot of things, like worker creation. Then you can diff that log when running in react and when running outside. Note you may want to diff the logs of the workers too.

[sophonet]

Thanks, I have turned on -sTHREADS_DEBUG and compared the console logs. I am pasting a side-by-side screenshot of the two versions - left: react - version (not running), right: stand-alone-version (running). Note that react (and similar frameworks) use vite or webpack to bundle all required js code into "compact" chunks, reducing the number of http-requests - this is why "Allocating a new worker thread" is called from "undefined" in the react version. Might that be the reason?

Other than that there are no big differences until the react version throws an error.

"In main 4" is output from the wasm's main() function and indicates the number of available threads. "WASM runtime initialized" is js console log from the Module's onRuntimeInitialized callback.

Any further idea?

[sophonet]

Update: When placing a second copy of app.js not only for bundling, but also in react's public directory for being used by the WebWorker initialization and defining its name in the Module definition as mainScriptUrlOrBlob, the app is running.

Obviously this is not clean since the main app() function initializing the module is downloaded twice, once in the code of the bundler for react (vite / webpack) and once for the worker from it's vanilla emcc output app.js. I have seen that Blobs can also be passed as URL to workers, but the Blob also needs to include the whole code of app.js, correct?

[sbc100]

Yes, bundlers can get a little confused by emscripten-generated multi-threadded code, because we call new Worker(..url_of_self..), which kind of means the code depends on itself. This can be hard for bundlers to grok I think,