Repository navigation
Add support for assigning names to worker_threads #32434
Description
Activity
I think the only concern here would be portability – Windows has
SetThreadDescription()/GetThreadDescription(), butpthread_setname_np()andpthread_getname_np()are non-portable. I guess that means that libuv needs to be taught how to recognize a platform that supports these, and that we have to accept it being a no-op on platforms that don’t.Reacted by Tobias Nießen@addaleax - couldn't we keep the name in the
Workerobject level only, rather than attaching it to the native thread?@gireeshpunathil You can already assign any properties to the
Workerobject that you want. That doesn’t seem to make sense to me in the use case described here, though.Adding support for thread naming to libuv isn't complicated but some thought has to be given w.r.t. #30061 (comment) - the current 1-to-1 correspondence between threads and workers need not be true forever.
I think all currently platforms let you set the thread name more than once, making it trivial to fix, but e.g. Fuchsia support would be problematic, because it only lets you set the name at thread creation time (AFAIK anyway - LMK if there is a way around that.)
Reacted by ExE Boss and Alex YangI am willing to take this, but this is in fact a mostly libuv project
Currently setting the process title uses a combination ofpthread_set_nameandprctlon Linux where you need to use both to have the same name in/proc/<pid>/command/proc/<pid>/cmdline
So one will have to take the existinguv_set_process_title()and extract auv_set_thread_title()from it for every supported OS
see #35503@cTn-dev ... Worker thread utilization with Node.js is a bit difficult. I would have to ask exactly what you're looking for. @trevnorris just recently landed a new metric capability in Node.js called "event look utilization" that measures how efficiently the event loop is being used. There are separate metrics available for the main event loop thread and each individual worker and Trevor's research has demonstrated it to be a solid replacement for CPU analysis -- even better in that there's zero noise from the entire process or other CPU tasks to filter out.
As both @addaleax and @bnoordhuis have pointed out, there's likely going to be some difficulty in consistently implementing the ability to name threads and it's not clear what the utility of doing so is really going to be, so better understanding the use case would be helpful.
@mmomtchev @jasnell Thank you for looking into this ticket again.
I have been indeed keeping an eye on the #34938 (haven't had time to try it yet, i will make sure to do so when v14 goes LTS).
From the instrumentation point of view i think its a viable alternative for "what i initially needed to do" (as the above functionality wasn't available before).The exact use case i was trying to tackle was long term monitoring of process & thread utilization when the utilization of worker threads is high or high amount of them is being used in a single process.
(I was tracking down a bottleneck that only manifested in production/couldn't repro locally, the inability to see which of the worker threads is being maxed out made the investigation much more time consuming).
While the process cpu usage clearly indicated that the cpu usage is for example 300%+, there was no "easy" way to determinate which of the worker threads are running "hot/cold" (beside seeing the threadId reporting utilization of X%).The end goal in my case was that named threads would provide quick and easy way of identifying worker threads that are heavily utilized/under utilized without additional instrumentation on the application level.
This would also likely help people get deeper insight into how cpu time is being spent on each thread inside the process (libuv thread pool, threads used for GC, worker threads, etc).Reacted by James M Snell@cTn-dev a quick and dirty solution will be to install one of the several syscall packages from NPM and then call pthread_setname_np
Just revisiting this... for all the reasons already given, it's unlikely that there will be a reliable way of assigning a thread name other than by attaching a property to the actual
Workerobject. Given that the use case is in monitoring the activity, having a centralize way of knowing that a thread has been made created and attaching any additional instrumentation to it is helpful. See #38659I'm going to recommend that we close this issue, however. If something gets added to libuv down the road we can revisit, but for now, using a userland module is likely the best option.
Is your feature request related to a problem? Please describe.
Describe the solution you'd like
new WorkerconstructorDescribe alternatives you've considered
Haven't considered any alternatives at the moment.
I am not sure if process.execArgv can be leveraged here to set a thread name as an alternative way of setting it.