| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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