What problem are you trying to solve?
With ESM Phase Imports specifying the ability to construct workers directly from both JS and Wasm module sources in #11152, a missing piece in this workflow is the ability to provide initial data as part of the initialization payload.
For WebAssembly in particular, to initialize a shared memory import for a worker while using this new new Worker(wasmModule) initialization sugar per this proposal, it would be a requirement to also have the ability to pass an initialization payload of the shared memory to bind to.
What solutions exist today?
Node.js worker threads have a commonly useful feature workerData which allows providing serializable data along with the worker construction as part of the initialization process. This data is then accessible from the child worker via a special import - import { workerData } from 'node:worker-threads'.
How would you solve it?
If adding a new initData or similar option to the options bag of the worker constructor, the main question seems to be how to make it accessible from within the worker, although perhaps it's as simple as self.initData?
Then, if we had a JS-based solution, Wasm might then be able to define something like a special import to access this as a Wasm-specific convention like (import "wasm:init-data" "memory") to "import" initialization data off this object.
Anything else?
Have there been previous discussions about accepting initial serialization payload as part of the new Worker() constructor options?
What problem are you trying to solve?
With ESM Phase Imports specifying the ability to construct workers directly from both JS and Wasm module sources in #11152, a missing piece in this workflow is the ability to provide initial data as part of the initialization payload.
For WebAssembly in particular, to initialize a shared memory import for a worker while using this new
new Worker(wasmModule)initialization sugar per this proposal, it would be a requirement to also have the ability to pass an initialization payload of the shared memory to bind to.What solutions exist today?
Node.js worker threads have a commonly useful feature
workerDatawhich allows providing serializable data along with the worker construction as part of the initialization process. This data is then accessible from the child worker via a special import -import { workerData } from 'node:worker-threads'.How would you solve it?
If adding a new
initDataor similar option to the options bag of the worker constructor, the main question seems to be how to make it accessible from within the worker, although perhaps it's as simple asself.initData?Then, if we had a JS-based solution, Wasm might then be able to define something like a special import to access this as a Wasm-specific convention like
(import "wasm:init-data" "memory")to "import" initialization data off this object.Anything else?
Have there been previous discussions about accepting initial serialization payload as part of the
new Worker()constructor options?