I have a multi-threaded application in a POSIX/Linux environment - I have no control over the code that creates the pthreads. At some point the process - owner of the pthreads - receives a signal.
The handler of that signal should abort,cancel or stop all the pthreads and log how many pthreads where running.
My problem is that I could not find how to list all the pthreads running in process.
You could wrap
ps -eLF
(or another command that more closely reads just the process you're interested in) and read theNLWP
column to find out how many threads are running.There doesn't seem to be any portable way to enumerate the threads in a process.
Linux has
pthread_kill_other_threads_np
, which looks like a leftover from the original purely-userland pthreads implementation that may or may not work as documented today. It doesn't tell you how many threads there were.You can get a lot of information about your process by looking in
/proc/self
(or, for other processes,/proc/123
). Although many unices have a file or directory with that name, the layout is completely different, so any code using/proc
will be Linux-specific. The documentation of/proc
is inDocumentation/filesystems/proc.txt
in the kernel source. In particular,/proc/self/task
has a subdirectory for each thread. The name of the subdirectory is the LWP id; unfortunately, [1][2][3] there doesn't seem to be a way to associate LWP ids with pthread ids (but you can get your own thread id withgettid(2)
if you work for it). Of course, reading/proc/self/task
is not atomic; the number of threads is available atomically through/proc/self/status
(but of course it might change before you act on it).If you can't achieve what you want with the limited support you get from Linux pthreads, another tactic is to play dynamic linking tricks to provide your own version of
pthread_create
that logs to a data structure you can inspect afterwards.Given that the threads are in your process, they should be under your control. You can record all of them in a data structure and keep track.
However, doing this won't be race-condition free unless it's appropriately managed (or you only ever create and join threads from one thread).
Any threads created by libraries you use are their business and you should not be messing with them directory, or the library may break.
If you are planning to exit the process of course, you can just leave the threads running anyway, as calling exit() terminates them all.
Remember that a robust application should be crash-safe anyway, so you should not depend upon shutdown behaviour to avoid data loss etc.