-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
lib: send the argv
to the ESM worker thread loader
#50916
Conversation
When the `--conditions` is sent to a worker thread, it should affect the worker thread with the ESM loader on it. This patch sends the `execArgv` to the ESM worker. Signed-off-by: Juan José Arboleda <[email protected]> Fixes: nodejs#50885
Review requested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @nodejs/workers
@@ -265,6 +265,7 @@ class Worker extends EventEmitter { | |||
setupPortReferencing(this[kPublicPort], this, 'message'); | |||
this[kPort].postMessage({ | |||
argv, | |||
execArgv: options.execArgv, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this affect all workers, not just the one for hooks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If InternalWorker is only created for hooks, the answer is yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does seem odd, especially when execArgv
is supposed to default to the parent for all Worker
cases. I would also have expected a change to the consumption API too. Where is this consumed internally that this change is needed?
I don't understand. Most of the changes are in ESM loader files, but no test is changed or added to confirm that something is fixed in this context. |
Look at test/parallel/test-worker-execargv.js |
Exactly my point. |
You are right, let discuss this a bit more, first ensure that this change only affects the esm-worker then I will polish this, give a better shape, thanks! Really, thanks! |
@@ -460,8 +463,8 @@ class CustomizedModuleLoader { | |||
/** | |||
* Instantiate a module loader that uses user-provided custom loader hooks. | |||
*/ | |||
constructor() { | |||
getHooksProxy(); | |||
constructor(execArgv) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update all jsdoc declarations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure this is the right approach. Per https://nodejs.org/api/worker_threads.html#new-workerfilename-options it’s up to the code calling new Worker
to define what should be passed into it, from argv
to env
to resourceLimits
and all sorts of things. I don’t think we want to keep updating Node core code every time a hook author wishes another thing from the main thread were passed into the hooks thread.
I think the original problem can already be solved via code like (untested):
// register.js
import { argv } from 'node:process';
import { register } from 'node:module';
register('./hooks.js', {
parentURL: import.meta.url,
data: { argv },
});
// hooks.js
export function initialize({ argv }) {
console.log(argv);
}
node --import ./register.js app.js
Before we go modifying core, perhaps something like this should be tried?
Thanks everyone for reviewing this. The issue is now closed, I’ll proceed to close this PR as well |
I just, had a lapsus 😂 re-opening, I'm still working on this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about --import
and --require
are these also in execArgv
? If so that would risk a deadlock situation in the recommended loader use case. These might need to then be filtered out I think.
@@ -265,6 +265,7 @@ class Worker extends EventEmitter { | |||
setupPortReferencing(this[kPublicPort], this, 'message'); | |||
this[kPort].postMessage({ | |||
argv, | |||
execArgv: options.execArgv, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does seem odd, especially when execArgv
is supposed to default to the parent for all Worker
cases. I would also have expected a change to the consumption API too. Where is this consumed internally that this change is needed?
Closing in favor of #50752 Refs: #50885 (comment) |
When the
--conditions
is sent to a worker thread, it should affect the worker thread with the ESM loader on it. This patch sends theexecArgv
to the ESM worker.Fixes: #50885