Repository navigation
Tracking issue: Worker support #13143
Description
I’m opening this as a discussion issue, as proposed in #2133 (comment), to see whether and how we can get (Web)Worker support into Node core.
This feature would be comparatively large, there’s quite a bit of pre-existing work that we will want to look at, and I imagine we might want to do an enhancement proposal (EP) first to make sure we don’t engage in too much unnecessary work. I imagine the roadmap is something like this:
- Create a new repository in the org to work under, for code, working out the EP text, discussion issues, and so on. This is something I can just do unless anybody objects to that in the near future.
- Find volunteers who are willing to do parts of the work, maybe even set up somewhat regular meetings.
- See if there are any immediate objections to a feature of this kind becoming a part of Node core.
- Figure out what the API should look like; How close to the WebWorker standard could and should we get? How much of Node’s standard modules should be available to workers (e.g.: we’d probably want timers but no I/O modules? or maybe we would want those?)? SharedArrayBuffers? Other magic?
- Take a look at work that has been done elsewhere, e.g. workers: initial implementation #2133 or @audreyt’s https://github.com/audreyt/node-webworker-threads, and see how much can be used, what went well/not so well, etc.; Also, I know @bnoordhuis has looked into this a lot, so it would be really good to hear his thoughts.
- Write an EP based on discussion around those topics.
- Get the CTC to approve that EP.
- Work on the actual code, documentation, tests, etc. in that extra repository.
- Open a pull request against this repository (nodejs/node) with the new code.
I can probably lead a bit of the effort, and I’ve considered doing this work alone, but so far it always ended at “this would be too much work for me to do on my own”; so if you want to help, please do, but expect to spend some time on this. ❤️
/cc @nodejs/collaborators @petkaantonov @NawarA @pemrouz
Activity
vkurchatkin commentedon May 21, 2017
Count me in. That's something that I've wanted for a long time to happen.
cjihrig commentedon May 21, 2017
I'm interested.
not-an-aardvark commentedon May 21, 2017
I'm interested.
aqrln commentedon May 21, 2017
If there is anything I could be of help, I'll be glad to be involved.
bnoordhuis commentedon May 22, 2017
In a multi-process model it's easy and cheap to expose everything.
In a multi-thread model a lot of work has to be done for seemingly trivial things. Example: the current working directory is a per-process property, not per-thread. Node needs to be taught to maintain a per-thread working directory and all file system operations must use it henceforth. That requires major surgery to the fs module,
process.chdir(), the module loader, etc. Native add-ons probably cannot be made to work at all.Another problem with the multi-thread model that the multi-process model doesn't have is that the address space on 32 bits architectures is limited to ~2 GB. A V8 isolate needs a lot of virtual memory to do anything interesting. 10 or 20 threads tops will exhaust the address space and kill the process.
I'd look into the multi-process model + shared memory. That lets you support SharedArrayBuffer without the headaches of the multi-thread model.
Cross-platform shared memory has issues of its own but they are tractable: it's mostly working around platform quirks and limitations. Drudge work but nothing that is insurmountable.
eljefedelrodeodeljefe commentedon May 22, 2017
I was also researching on it, basically concluding to wait for SharedArrayBuffer and then to do a multi-process model. What would help is having Node as shared library.
pemrouz commentedon May 22, 2017
Thanks for taking a lead on this @addaleax! You can count on me too :)
NawarA commentedon May 22, 2017
+1
I've produced a model of communication that I believe is simple enough, happy to share and help work on some architecture and code. Working together, I'm sure we can produce something simple and great
refack commentedon May 22, 2017
Sounds like a very interesting venture.
Would love to help!
refack commentedon May 22, 2017
That sound like a very JSy concept. I'm +10
(Which makes this a little like turning
clusterinto standard complaint and implementing on Windows, for which I'm +100)zimbabao commentedon May 23, 2017
Very interested on working on this, count me in.
bmeck commentedon May 23, 2017
I'd be interested but only if we don't implement process level shared mutable state (like what @bnoordhuis was getting at). I'd also lean on not supporting any specific module system (CJS or ESM) in first implementation.
refack commentedon May 23, 2017
@mbeck that interesting...
I'm interested in your POV, could you elaborate on two points?
new Worker(runFunc))?mhdawson commentedon May 23, 2017
@JiapengZhu this may line up with some of the performance investigation you are looking at.
8 remaining items
benjamingr commentedon Oct 9, 2017
@jasnell (cc @bnoordhuis )
What do you mean? There is currently no way to utilize all cores on the same memory in Node.js, workers let you do that - letting Node.js support a whole variety of use cases it has traditionally not been able to support.
For me half of the point is SharedArrayBuffer, this means you can share memory between worker threads in Node.js. The API itself isn't the most critical part, but keep in mind:
This is about adding a capability to Node.js. Now, it's certainly not the only API but given we're not going to implement locking throughout V8 and V8 won't implement threading with objects the way Nashhorn supports because it makes no sense for the DOM web platform - I think this is about the best we can do.
Optimally, I'd like something like sharing objects (and closures) between threads, synchronization primitives like a
Mutexand other concurrency primitives - but given how V8 is built that is likely to never happen. Given that - the worker model with shared memory through SharedArrayBuffer is the next best thing.jasnell commentedon Oct 9, 2017
Yes, I know all of those reasons, and agree with them. I Was not asking what the use cases are, I was saying that we need to document them rather than assuming that everyone will consider it obvious. This is a significant new capability, code is fantastic, code with motivating and documented detail is even more so.
bnoordhuis commentedon Oct 9, 2017
Minor tangent: mutexes, rwlocks, condition variables, barriers, etc. can be constructed out of Atomics.wait() and Atomics.wake().
benjamingr commentedon Oct 9, 2017
First of all thanks, I didn't know that. Second of all - IIUC it would still only allow sharing memory in a SharedArrayBuffer (raw, binary(ish) data) - right?
(At which point the API of Atomics.wait() and Atomics.wake() seems sufficient)
bnoordhuis commentedon Oct 9, 2017
@benjamingr Yes, that's right.
yorkie commentedon Jan 9, 2018
Sorry about missing you message @jasnell, I'd glad to merge Rokid/node-webworker into core if possible, could we have a discussion about this? Do you have any suggestion?
/cc @TimothyGu @addaleax
devsnek commentedon Jan 9, 2018
if we can make workers use esm imo it would be much nicer than monkey-patching in some require-like method. as to the stuff further up, letting these "workers" handle io, including sockets, would be a pretty cool feature, as annoying as it would be to implement.
and as a side note, i think every thread implementation i've seen for v8/node has the same issues with v8's heap allocation (including mine and @yorkie's)
yorkie commentedon Jan 9, 2018
Handling I/O including sockets should be done at WebWorker and easy to implement, but that's just handling in worker, we have to listen connections on master.
As for ESM in worker, that's good idea, and it could be separately implemented inside worker place :)
TimothyGu commentedon Jan 9, 2018
I believe ESM in workers are already supported in the https://github.com/ayojs/ayo implementation.
devsnek commentedon Jan 9, 2018
those look pretty nice, and they handle seem those heap allocation issues i mentioned earlier, perhaps @addaleax you can look into what needs to be done to get something similar in node core?
aaronleeatali commentedon Mar 26, 2018
I wish you can take a look at here. https://github.com/alibaba/AliOS-nodejs/wiki/Workers-in-Node.js-based-on-multithreaded-V8
We propose a system for asynchronous multithreading with an API confirming to Web Worker standard in Node.js and maybe the performance improvements show that it's worth the effort.
jasnell commentedon Sep 21, 2018
@addaleax ... now that things are progressing along nicely with workers, does this issue need to remain open?
apapirovski commentedon Oct 26, 2018
Sounds like we can close this? Everything mentioned here has been done. If another tracking issue needed, there should probably be a new one that's more current and isn't as much of a commitment to read through.