Description
The pthreads mode seems to interact poorly with use of MODULARIZE to encapsulate modules as objects, which I use heavily in ogv.js video player to create the various demuxer and decoder plugins (I'm trying to get multithreaded decode working with libvpx.)
First problem: the setup code checks document.currentScript.src for the URL to pass down to the pthreads worker to load its code. This fails because document.currentScript is only available during script immediate execution, but the module is being instantiated later by calling code.
Possible workaround: check document.currentScript.src early (not inside the wrapper function) and store the value on the Module object for later use. Or, at least allow it to be passed in via a Module input property.
Second problem: pthread-main.js expects that the module will live in the global Module object and be suitably initialized directly after the importScripts() call. This is not the case with modularization.
Possible workaround: send the exported class name (EXPORT_NAME option) down to pthreads-main.js via the postMessage, along with the URL to the .js. If present, instantiate:
importScripts(e.data.url);
if (e.data.exportName) {
Module = new global[e.data.exportName](Module);
}
Third problem: pthread-main.js expects to share global state with Module:
Used as globals from pthread-main.js, already exposed as props on Module (very easy to fix):
- Runtime
- HEAPU32
Set via globals from pthread-main.js and cannot reach Module (need to be explicitly transfered via Module options or otherwise):
- ENVIRONMENT_IS_PTHREAD
- buffer
- PthreadWorkerInit
- tempDoublePtr
Used as globals from pthread-main.js but not exposed on Module (can easily be exposed as props):
- __register_pthread_ptr
- assert
- PThread
- _pthread_self
- _emscripten_futex_wake
- asm