-
Notifications
You must be signed in to change notification settings - Fork 2k
Closed
Labels
Description
Currently we exclude Node from the threaded build of the WASM backend (#3829). The threaded build fails in Node for several reasons:
- In Emscripten SDK v.1.39.15 (this is what we're using), the web worker code includes the line
Worker = nodeWorkerThreads.Worker, which is problematic becauseWorkeris undefined. Emscripten v.1.39.16 contains a fix for this: emscripten-core/emscripten@cccf9bf. We need to update to 1.39.16 (which means addressing several compile errors). - We are currently using the
BlobAPI for the threaded build in order to narrow down thewasm.mainScriptto just the Emscripten-generated WASM module, rather than our entiretf-backend-wasm.jsbundle (which contains the Emscripten-generated WASM module). We need to narrow it down because the worker ingestswasm.mainScriptthroughimportScripts, and the worker can't ingest our whole bundle because it contains TFJS code that the worker doesn't know anything about (hence it immediately throws an error if attempting to ingest the whole bundle becauserunKernelis undefined). We need to polyfillBlobfor Node, the way we do forfetch. - Launching a simple node program with the necessary experimental flags to ask for the threaded + SIMD build (e.g.
node index.js --experimental-wasm-simd --experimental-wasm-threads --experimental-wasm-bulk-memory) fails with the following message:
requested a shared WebAssembly.Memory but the returned buffer is not a SharedArrayBuffer, indicating that while the browser has SharedArrayBuffer it does not have WebAssembly threads support - you may need to set a flag (on node you may need: --experimental-wasm-threads --experimental-wasm-bulk-memory and also use a recent version)` (from Emscripten).
patrickhulce and adam-lebon