esm: spawn only one hooks thread

[GeoffreyBooth]

Our intent with moving module customization hooks into a separate thread was that one such “hooks thread” would be spawned regardless of however many worker threads the user’s application code spawned. On current main this is not the case; a new hooks thread is created alongside each new worker thread.

This PR aims to fix that, but currently all I have is a test that fails on current main but should pass, once this bug is fixed. I’m opening this as a placeholder for when a fix is ready, and I encourage anyone who wants to take a crack at it to help make this test pass. I’m happy to let others push commits on my branch.

cc @nodejs/loaders @nodejs/workers

[JakobJingleheimer]

Posting this here in case someone else is working on this:

I think the problem looks like:

node    → instantiate HooksProxy
          ↳ spawn InternalWorker
                   
app.js  → spawn Worker
          ↳ instantiate HooksProxy
            ↳ spawn InternalWorker

The various HooksProxys need to always connect to the same InternalWorker. I think the way to do that is to have the "main" MessageChannel::port2 (instantiated by node itself) available to the various HooksProxys. They use that to send their message to InternalWorker and include their own MessageChannel::port2 for InternalWorker to respond back (listening on their own MessageChannel::port1, not main's).

Each HooksProxy needs to instantiate its own lock and pass that to the (possibly existing) working.

PS Sorry, I may be getting the port numbers mixed up (documentation for these are always the most convoluted possible 😩). In the above, InternalWorker receives all messages (regardless of originating thread) on the same port; it then responds back to the originator's (own) provided port.

[GeoffreyBooth]

Fixed by #52706

[GeoffreyBooth]

For those of you subscribed to this thread, I just posted nodejs/loaders#201 to ask for your feedback on what direction you think this API should go.