tags:

views:

91

answers:

3

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.

A: 

You could wrap ps -eLF (or another command that more closely reads just the process you're interested in) and read the NLWP column to find out how many threads are running.

sarnold
Thanks but I'd rather go for an API call - if exists. I don't know how could I stop or destroy the pthreads with this solution though.
msalvadores
@msalvadores, true, stopping the threads from within the program wouldn't work with my hacky answer -- but you could exit(2) the process right then and there, or your signal handler could set a global variable that the threads periodically check; when it is set, the threads exit.
sarnold
+3  A: 

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/$$ where $$ is your process ID. 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 in Documentation/filesystems/proc.txt in the kernel source. In particular, /proc/$$/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 with gettid(2) if you work for it). Of course, reading /proc/$$/task is not atomic; the number of threads is available atomically through /proc/$$/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.

Gilles
@Gilles thanks a lot for your reply. I like your last solution. I'll investigate that one a bit. I'd rather avoid reading /proc/ stuff mainly because of portability issues.
msalvadores
A: 

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.

MarkR