Repository navigation
esm, loader: move to own thread #43658
Description
Activity
@bmeck @MylesBorins could either of you speak to the impetus for this?
@bmeck @MylesBorins could either of you speak to the impetus for this?
Pros and cons here: nodejs/modules#351 (comment)
Can add to the list of package authors:
esmockI wonder, does it make sense for the loaders team to have a thread somewhere which can be subscribed to for notifications of breaking changes? All relevant discussion can happen elsewhere, the thread would be like an RSS feed. Package maintainers can opt-in to notifications of breaking or potentially exciting/disruptive changes by subscribing to that thread.
Might scale better than us hoping we know a comprehensive list of all loaders.
Since Node.js doesn't maintain anything of the sort, that sounds like a better alternative to "surprise!". It's not full-proof, though.
We have a working Proof of Concept: https://github.com/JakobJingleheimer/worker-atomics
- changed the title
[-]esm, loaders: move to own thread[/-][+]esm, loader: move to own thread[/+]on Sep 18, 2022 7 remaining items
There's also a potential benefit in moving non-custom loading off-thread as it would protect internals from prototype pollution (I think). That would argue that we should make this same refactor for CommonJS too.
Reacted by Jacob SmithThis is a significant blocker for me as Node.js is often used in environment that are constrained by memory. At the bare minimum we should investigate:
- how much more memory is needed?
- how much more latency this will add?
- can we avoid it, i.e. only move user-provided code off thread?
- will this memory cost disappear or will the thread be kept around?
@mcollina I'm not convinced we can answer those questions before we have a fully working implementation; without data, we can only make assumptions, and I wouldn't want us to draw a conclusion over possibly baseless assumptions.
Reacted by Matteo CollinaAbsolutely! I'm concerned about the addition to our startup memory footprint, as this matters for some of our usecases.
I'm flagging that this might be problematic and I was surprised because it was not mentioned in the main text of the issue.
A few more question:
- if a new Worker thread is spawned in the lifetime of the application, will this create another thread to load ESM?
- what about dynamic import? Will it need re-spawning the thread?
A few more question:
- if a new Worker thread is spawned in the lifetime of the application, will this create another thread to load ESM?
- what about dynamic import? Will it need re-spawning the thread?
In both cases, (in the current design/implementation) only if the "loaders" worker is not around (otherwise it will be re-used).
In both cases, (in the current design/implementation) only if the "loaders" worker is not around (otherwise it will be re-used).
So there is only one loaders worker for all worker threads created by Node.js?
No, there's a separate loaders worker for each worker thread.
I assume it should be possible to configure loader hooks per worker thread therefore this may complicate this thread.
I'm also a bit skeptical to have a single loader thread for all workers as this seems to allow "leaking" data between workers which should be isolated. Also this single loader worker would be parallelism blocker.
The comment from @targos and @JakobJingleheimer seem contradictory?
There are 3 different threading models being considered, that I'm aware of.
Sorry, I think #43658 (comment) is the intended behaviour (the current PR may not achieve that yet). The rationale being that workers are intended to be isolated, so their loaders' state should also be isolated/fresh.
Quick update from our recent team meeting: We invited Gil Tayar (author/maintainer of several pertinent libraries) to discuss spawning a dedicated loaders thread per user-land thread, and he noted that will add enormous complexity to library authors (on top of the extra complexity on node's side). We decided for an initial implementation, it would be better to use a single loaders thread shared by all user-land threads and add caveats to the relevant sections of the docs. If there is sufficient appetite, we can subsequently add a configuration option (perhaps to the
Workerconstructor) to spawn dedicated loaders threads.Reacted by Matteo Collina and Gil TayarWas there any progress on not spawning any thread if no custom loaders are defined?
Yep! nodejs/loaders#118 (comment) and I believe this should be logistically/technically possible.
Reacted by Matteo Collina and lin72h
What is the problem this feature will solve?
import.meta.resolve()For the initial implementation, the same loaders thread will be used for all user-land threads. A subsequent enhancement may add a configuration option to the
Workerconstructor to spawn its own dedicated loaders thread.What is the feature you are proposing to solve the problem?
Move loaders off-thread
What alternatives have you considered?
No response
Per direction from TSC
Following in the vein of babel: babel/babel#14025
And https://github.com/bmeck/using-node-workshop/tree/main/steps/6_async_and_blocking