worker: initial implementation

[addaleax]

Implement multi-threading support for most of the API.

So far reviewed by @Qard

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included (later)
• documentation is changed or added (later/other PR)
• commit message follows commit guidelines

Affected core subsystem(s)

worker

[Qard]

Not sure how I feel about putting isMainThread in the module wrap. It's probably best to avoid adding more things to top-level global/module scope, especially given that this won't work for es modules.

Perhaps there was some misunderstanding, but my comment on the previous iteration about isMainThread was just about turning process.binding('worker').threadId === 0 in the few places it occurred internally into process.binding('worker').isMainThread by adding a getter for that in the native bindings. That would make the handful of places that threadId === 0 is used a bit clearer.

[TimothyGu]

I'm also inclined to make the 'worker' binding internal to avoid any misuse by the userland.

[addaleax]

especially given that this won't work for es modules.

If we ever migrate core modules to ESM, we’re going to have to do a lot of refactoring anyway…

by adding a getter for that in the native bindings

It doesn’t feel quite right to do that to me, this really is a property of the whole Node environment rather than a single module. Also, it doesn’t quite seem like the bindings are the best place for usability helpers…

I'm also inclined to make the 'worker' binding internal to avoid any misuse by the userland.

Right, yes. This PR was written before they existed but we should definitely do that :) Done!

[Qard]

Userland code might try to use isMainThread too though, and not port cleanly when switching to es modules in the future. We already have require('workers').isMainThread, which I think should be the recommended mechanism, much like require('cluster').isMaster.

As for the binding for isMainThread, I just figured that would make the internals a bit cleaner, but it's only needed in a couple places. I'm not going to block on that.

[addaleax]

@Qard Oh – icymi, since nodejs/node@e6dfd59be02c3 the internals and userland code don’t share their module wrapper anymore, so isMainThread and internalBinding aren’t actually available. :)

[Qard]

Ah, cool. I was aware of the internalBinding stuff, but I hadn't reviewed it yet so I wasn't aware the module wrappers were split. 👍