tags:

views:

222

answers:

2

I need to find the number of signals pending in the signal queue of a thread in linux. Is there any API that is provided by Linux ?

This API needs to be called from thread, other than the thread we are querying.

sigpending gives the API for the calling thread. Is there any API, which takes thread id as arg, and provides some information about the signals pending in the queue.

Any help is appreciated.

+2  A: 

I'm not aware of such an API but here is a workaround: Write a small library which wraps the signal code. When you send a signal, increase an atomic counter. As you process the signals, decrement the counter again. Then, you can use this atomic counter to answer your curiosity.

[EDIT] If that is not enough, then you have the source: Just examine the code and the data structures involved and use what you need to peek into the kernel structures. But this might involve writing a module (because the data structures of the kernel aren't readable by a process) plus your code will become dependent on the kernel on which it was compiled. So I advise against this approach.

Aaron Digulla
This is what I've seen most do to find pending (unserviced) RT signals. Others are just combined (by type) by the kernel anyway, which may be worth noting. 10,000 SIGUSR1's get delivered as 1.
Tim Post
+4  A: 

sigpending() returns the set of signals pending delivery for a thread. You can iterate over that sigset_t and use sigismember() to test for membership.

Traditionally, UNIX does not queue more than one instance of a signal (in this sense, they continue to be "unreliable"). Sometimes you can get this effect with realtime signals.

On Linux, read()ing from a signalfd will allow more than one instance of a signal to be read at once, should they be queued.

nick black