Pthreads no longer allow user to have custom instantiateWasm function

[shinji-TH]

Hi @sbc100 ,
I'm upgrading my app from EMSDK 3.1.41 and noticed that in #21701 , pthreads now have their own instantiateWasm functions.

emscripten/src/runtime_pthread.js

Line 68 in e6ed9d3

Module['instantiateWasm'] = (info, receiveInstance) => {

My app uses our own instantiateWasm to perform initialization logic for the main threads and worker threads.
Hence wishes to check if this change is as expected and if there are any recommendations to have worker threads to initialize any custom code before calling var instance = new WebAssembly.Instance(module, getWasmImports());

[sbc100]

Interesting. Even before #21701 we still used the instantiateWasm method in workers to load the wasm file:

emscripten/src/worker.js

Lines 97 to 114 in 9f19ec9

	#if !MINIMAL_RUNTIME
	Module['instantiateWasm'] = (info, receiveInstance) => {
	// Instantiate from the module posted from the main thread.
	// We can just use sync instantiation in the worker.
	var module = Module['wasmModule'];
	// We don't need the module anymore; new threads will be spawned from the main thread.
	Module['wasmModule'] = null;
	var instance = new WebAssembly.Instance(module, info);
	#if RELOCATABLE || MAIN_MODULE
	return receiveInstance(instance, module);
	#else
	// TODO: Due to Closure regression https://github.com/google/closure-compiler/issues/3193,
	// the above line no longer optimizes out down to the following line.
	// When the regression is fixed, we can remove this if/else.
	return receiveInstance(instance);
	#endif
	}
	#endif

I wonder if the different is that this used to come before the preJS files and now is comes after? Or some kind ordering thing like that? How are you injecting your instantiateWasm?

[sbc100]

It seems like we were already depending on the instantiateWasm from worker.js being used since it was setting up the wasmPromiseResolve promise. Was you custom instantiateWasm also doing this?

[shinji-TH]

Yup, the instantiateWasm function was there previously.
However when we call loadWasmModuleToWorker, we overwrite the function by providing the worker with the Module of the main script.

emscripten/src/library_pthread.js

Line 381 in 9f19ec9

'urlOrBlob': Module['mainScriptUrlOrBlob']

Hence, during initialization, the worker threads run with the user's version of instantiateWasm instead of the worker.js copy.
In the new change, since there was no need for worker.js, instantiateWasm was loaded with the threads version as it is packed in as the last in the javascript.

[sbc100]

I just landed a change the re-introduces instantiateWasm in pthread workers: #22912

However, even after this change I fear that #21701 may have change pthread creations in other ways that break your use case since urlOrBlob is not longer passed to new workers. mainScriptUrlOrBlob can still be used to tell emscripten how to find main script, but this is then used directly to create new workers rather then passed as an argument to the separate worker.js file (which no longer exists).

Perhaps you can say more about what you are trying to do in your instantiateWasm withing your pthread workers? Pthread workers already have access to the wasm module directly so they should know how to instantiate it.

[shinji-TH]

We are using instantiateWasm for a few things

• Initialization of WebGPU
• Creation of offscreen canvas.
• initialization of service worker channel

Thanks for helping to land the changes!

[sbc100]

I see, but none of those actually effect instantiation of the module on each thread do they? Are thos per-thread startup tasks that you want to perform on each worker as it starts up?

[shinji-TH]

Yes, those are per-thread startup tasks due to our legacy code, where we render within the thread worker, as it is faster than proxy calls in our previous profiling.

[sbc100]

And then how does your version of instantiateWasm actually perform the task of instantiation? Where does it find the wasm module?

Is the work you need to do, per-pthread or per-worker? I'm hoping we can give you some other hooks since I don't think instantiateWasm sounds like the right place to do that work you are talking about here.

[sbc100]

One more clarifying question: What are you trying to do in the pthreads' instantiateWasm is that is different from simply instantiating the recieved module? Are you using the module that is received via postMessage (previously referred to as Module['wasmModule']) or are you retrieving it some other way?