Tracking issue: Worker support

[addaleax]

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:

1. 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.
2. Find volunteers who are willing to do parts of the work, maybe even set up somewhat regular meetings.
3. See if there are any immediate objections to a feature of this kind becoming a part of Node core.
4. 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?
5. 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.
6. Write an EP based on discussion around those topics.
7. Get the CTC to approve that EP.
8. Work on the actual code, documentation, tests, etc. in that extra repository.
9. 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

[vkurchatkin]

Count me in. That's something that I've wanted for a long time to happen.

[cjihrig]

I'm interested.

[not-an-aardvark]

I'm interested.

[aqrln]

If there is anything I could be of help, I'll be glad to be involved.

[bnoordhuis]

How much of Node’s standard modules should be available to workers

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]

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]

Thanks for taking a lead on this @addaleax! You can count on me too :)

[NawarA]

+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]

Sounds like a very interesting venture.
Would love to help!

[refack]

I'd look into the multi-process model + shared memory.

That sound like a very JSy concept. I'm +10
(Which makes this a little like turning cluster into standard complaint and implementing on Windows, for which I'm +100)

[zimbabao]

Very interested on working on this, count me in.

[bmeck]

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]

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.

@mbeck that interesting...
I'm interested in your POV, could you elaborate on two points?

1. Would you prefer threads with shared mutable state? Or multi-process but with serialized communication?
2. If no modules, then code can only be passed from the master (a la new Worker(runFunc))?

[mhdawson]

@JiapengZhu this may line up with some of the performance investigation you are looking at.