-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: ability for tooling to pass data to workers and inject NODE_OPTIONS #30992
Comments
It seems like the event listener approach would at least allow some censoring/protecting of options? You could use Object.freeze etc on the options? |
@bmeck I prefer the event listener approach since it allows calculation of data and NODE_OPTIONS to happen when the thread is being created instead of needing to know those values way ahead of time, I'm not sure it helps give any special protection to the options that are specified. One drawback of using the events API is that I'm not sure Given the PR to run loader hooks in a worker thread I have to ask how you see this interacting with loader hooks? I assume loader hooks thread will always start before any |
That is my presumption yes. |
The `worker.platformData` and `worker.setPlatformData()` APIs allow an arbitrary, cloneable JavaScript value to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that `platformData` is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of nodejs#30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com>
The `worker.platformData` and `worker.setPlatformData()` APIs allow an arbitrary, cloneable JavaScript value to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that `platformData` is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of nodejs#30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com>
The `worker.platformData` and `worker.setPlatformData()` APIs allow an arbitrary, cloneable JavaScript value to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that `platformData` is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of nodejs#30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of nodejs#30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of #30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #37486 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of #30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #37486 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of #30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #37486 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of nodejs#30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: nodejs#37486 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
These APIs allow arbitrary, cloneable JavaScript values to be set and passed to all new Worker instances spawned from the current context. It is similar to `workerData` except that environment data is set independently of the `new Worker()` constructor, and the the value is passed automatically to all new Workers. This is a *partial* fix of #30992 but does not implement a complete fix. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #37486 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Darshan Sen <raisinten@gmail.com>
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment. For more information on how the project manages feature requests, please consult the feature request management document. |
Is your feature request related to a problem? Please describe.
nyc 15 is moving away from
spawn-wrap
, will useprocess-on-spawn
andnode-preload
in it's place. These two modules ensure nyc gets properly loaded into new processes, but they do not help with worker threads (note spawn-wrap also did nothing to help with worker threads). I'd like to add worker thread support to nyc.Describe the solution you'd like
nyc needs to pass data to worker threads without requiring modifications to arguments of
new Worker(...)
run by the code being tested. An idea I have:The above code assumes that
new Worker()
internally calculatesoptions.nodeOptions
based on theenv.NODE_OPTIONS
passed to it (see also #29117). This would allow nyc to inject preload modules if necessary without altering theprocess.env
of the new thread.Describe alternatives you've considered
Setting platform data during process startup could work for some use cases:
This would work for nyc but maybe another tool would need to calculate the object needed for platformData at the time of
new Worker()
. This is why my proposal is for 'worker spawn' hooks to ensure this is useful for more than just nyc. I'm also unsure howplatformNodeOptions
would be incorporated into theenv.NODE_OPTIONS
given tonew Worker()
.I considered patching the
worker_threads
core module.worker.SHARE_ENV
is very problematic for this approach as it eliminates the possibility of using environmental variables to get nyc options into the worker threads. We would likely need to patchnew Worker()
to wrap worker data so thatoptions.workerData = {userData: options.workerData, nycData}
, thenrequire('worker_threads').workerData
would be patched to return theuserData
subproperty and we'd create arequire('worker_threads').nycData
export. This seems like it would be very messy, especially if any other tooling had a need to patchworkerData
in a similar way. I'm really not interested in this approach even if it could be forced to work.CC @addaleax @arcanis @nodejs/tooling
The text was updated successfully, but these errors were encountered: