You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Node.js `worker_threads` are different than browser `Worker`s in that
they start spawning synchronously without waiting for an event loop
tick.
If we can also avoid waiting for the "loaded" event from the worker
before sending pthread messages to it, then we can spawn new pthreads
"synchronously" (prepare everything within the same event loop tick),
and block the current thread, making the behaviour on Node.js a lot
closer to native and avoiding the need for a pthread pool even without
Asyncify or extra helper workers.
That's what I did in this implementation. Instead of waiting for the
worker to tell us it's loaded and ready, I'm sending all commands
immediately to the worker. The worker accepts the first "load" message,
starts initializing the runtime, and meanwhile queues up any further
messages such as "run". Once the runtime is ready, it processes the
queue.
I could limit those changes only to Node.js, but it's easier to do both
together, allows to avoid a custom `worker.runPthread` callback, and
should be in theory even a bit faster in browsers too (by avoiding the
"loaded" roundtrip).
0 commit comments