Repository navigation
Give a name to a Worker (for debugging purpose) #41589
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Jan 19, 2022 @nodejs/workers
- addedworkerIssues and PRs related to the worker_threads module and Worker API.Issues and PRs related to the worker_threads module and Worker API.
on Jan 19, 2022 I wonder why the
process.titleand--titleAPis are explicitly not supported for workers.@targos @benjamingr I don’t think we ever specifically thought about Worker names in the context of the inspector. #32434 also has a bunch of information about why we did not implement other kinds of APIs for naming Workers (yet).
Reacted by Benjamin GruenbaumThere 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.
- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 19, 2022 I still believe adding name to the worker object rather than the worker's native thread (that suffers from portability issues) will be useful to some class of user scenarios - for example the tools (such as report, llnode etc.) can be taught to retrieve and display the worker names. Also, having a standard way of doing this such as in the worker constructor as opposed to the programmer explicitly adding it as a property makes the observability much more consistent.
Reacted by Quentin Gruber, Will Frew, Ingvar Stepanyan and Michael Auerswald- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 20, 2022 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.
- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jan 17, 2023 Can we not just get an optional 'WorkerPrefix' parameter that falls back to 'Worker'? That seems like a rather simple change to me?
Reacted by Quentin Gruber- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jan 21, 2023 @flipswitchingmonkey I don't think there are any major objections, it just needs someone to do the work. Pull request welcome.
I'm inclined to say it should be an
inspectormodule method but open to being convinced otherwise.My c++ is half a decade out of use, but I might have a look...
A quick glance at the code shows me that at
we are also setting a name for the Worker thread, again hardcoded (this time toLine 267 in d15a6ba
std::string name = "WorkerThread "; WorkerThread+id), so it would probably make sense to somehow combine those into a single customisable prefix?That's used for tracing. The inspector name is generated here:
node/src/inspector/worker_inspector.cc
Line 19 in d15a6ba
info_(BuildWorkerTitle(id), url, worker_thread),
Of course it'd be good to have them be consistent. Perhaps the trace name can be computed fromWorkerInfo::titleor the other way around.- added a commit that references this issue
on Mar 6, 2023 - added 2 commits that reference this issue
on Mar 13, 2023 - added a commit that references this issue
on Apr 11, 2023
What is the problem this feature will solve?
While debugging my Node.js app in VS Code, I've been trying to figure out which of the workers that are running is responsible for what, but found it hard to follow the flow as the workers were named
Worker ${index}instead of having a more descriptive name. Since I'm heavily depending on workers and passing them any heavy job I encounter from time to time, I want to be able to track which of them is active at the moment during runtime.What is the feature you are proposing to solve the problem?
It would be great if you could allow passing an optional param to specify a name/title for the worker, so we can later on use to track which of the workers are running (by name and not by a random number).
What alternatives have you considered?
No response