Re: pthread_sigaction() ?

[Xavier Roche <roche at exalead dot com>]

On 05/18/2011 03:11 PM, Jonathan Nieder wrote:
> Could you elaborate on the use case?  When this thread receives the
> signal, after doing something special does it call the old global
> signal handler?

No ; my two use cases were typically:
* the ability to interrupt a thread doing purely computational 
processing (ie. no risk to be inside some malloc critical section, for 
example) by sending (pthread_kill()) a specific signal to this thread
* the ability to return gracefully after a stack overflow (taken from a 
discussion on comp.unix.programmer ; see 
<https://groups.google.com/group/comp.lang.c/msg/dab652d5f92f67cb>)

> On the other hand, if you are writing library code and do not control
> what SIGUSR1 is used for in general, then there is a risk that someone
> will use kill(2) to send SIGUSR1

That's right -- the use case won't work if kill() is used. Some 
cooperation from the process (ie. not using kill() at all, for example) 
would be required anyway.

> I suppose I would suggest using a global signal handler that reads
> a thread-local variable to decide what to do.

Yep, that's what I did at the end. But in theory, pthread_getspecific() 
/ pthread_setspecific() can not be used in a signal handler ; at least 
these functions are not officially documented as being signal-safe. 
(some systems, such as Unix running on IBM systems, do declare these 
interfaces as safe ; but not Linux/glibc)

> would work, presumably; letting applications take care of it means the
> cost of an extra thread-local variable does not have to be paid by
> applications that don't need it.

Yes, good point. Thanks for the examples too, which demonstrate the 
issues behind thread-specific signal handling.