-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
worker_threads compatibility? #10
Comments
This seems worthwhile! It would also be interesting to see if it could be handled automatically by I've been following Node's workers stuff and would be interested in collaborating if you're looking at a shim layer. |
My primary concern here right now is Node.js going stable with worker_threads before these workflows as discussed above have been explored at all, by anyone. If there are issues / frictions I think it would be important to get that into the Node.js feedback process before worker_threads are unflagged as experimental and the API is cemented. Perhaps all will be fine though, in which case, great. This project seems the closest to the edge of future worker build workflows that I can find right now - thanks for being open to have the discussion here. |
Sorry for falling off this thread - I agree. I am going to try to find some time to set up tests against worker_threads so I can see what the delta is between what we output today and what needs to be supported. I'm curious if you envision |
Definitely, would be good to DM further about this if you have a moment. |
Node 12 is out, shipping worker_threads without the feature flag. Might be the right time to get back to this? 😉 |
Also interested in this feature! |
@guybedford and I ended up coming up with a longer-term plan for this, which should be easy to support in Worker Plugin. In the interim, I believe the following should work today with Worker Plugin: const { Worker } = require("worker_threads");
const worker = new Worker("./my-worker.js", { type: "module" }); |
@developit that seems like a good approach. It's worth noting though that there are a lot of differences between worker threads and native workers. See eg nodejs/node#30682 (comment). The simple difference from your example is The list is basically:
I think this is simply too much compat friction for your approach mentioned above to work for any user that doesn't have half a day to mess around with this stuff.... |
Good point, agreed! I think the shim module is probably a better way forward. Need to release it.. |
any updates? |
We're using worker-plugin (and I now need it to work from node too). I was hoping to find a comparison with https://github.com/developit/web-worker But having read this thread I'm wondering if web-worker is basically the solution being described here? Would love to hear from someone if there are downsides to switching from worker-plugin to web-worker. |
@DarrenCook I believe the solution is to use both. worker-plugin generates the code for the worker, and web-worker provides a Worker global that can be used by that code. You likely need to do something like this:
|
Understood if this is off-topic, and feel free to close, but I was just wondering if you'd considered compatibility with Node.js worker_threads here at all?
It seems like the sort of thing that would be generally useful for Node.js optimization as well, in having some kind of --node output, since you're already in the game of worker builds.
Although perhaps, a translation layer from web-style workers to Node.js-style worker_threads would be the better route as its own project.
Otherwise do you know anyone working on this problem / who considers this important?
The text was updated successfully, but these errors were encountered: