-
Notifications
You must be signed in to change notification settings - Fork 10
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
engine: workerpool shares module scope #410
Comments
Does burning the thread even help? yes: each thread has its own module context, so if we can burn the thread, we'll get a clean new module in the next one. |
Calling This second bit is a real problem. |
Working around the cache with a UUID might not be too hard - if we dynamically import with a query, id `import('common?cachebuster=abc'). I think this bypasses node's module cache but will still resolve to the correct file. Difficulty: I think this will leak memory because the old module won't be garbage collected. That again tells me we should burn threads regularly. Ok, so what if the worker has its own sort of GC and, on an interval, says "if there are no pending tasks, terminate all threads". That means we can cache bust but also free up memory and never lose a pending job. |
Really interesting thread about unloading: nodejs/tooling#51 Using our own loader which doens't cache and re-evaluates the module is a good solution. It won't reclaim memory. Adding a cache busting URL is gonna be way easier. I think the previous comment is the winner here. |
The problem:
See #404 (comment) and #404 (comment) (Maybe I'll write this up again later)
We need to ensure that each run executes with a clean module scope, ie, any intialisation code is re-run before the workflow starts.
Possible list of solutions:
The text was updated successfully, but these errors were encountered: