Re: A signal fairy tale

["Daniel R. Kegel" <dank@alumni.caltech.edu>]

Christopher Smith <x@xman.org> wrote:

> Jamie Lokier <lk@tantalophile.demon.co.uk> wrote:
> > Btw, this functionality is already available using sigaction().  Just
> > search for a signal whose handler is SIG_DFL.  If you then block that
> > signal before changing, checking the result, and unblocking the signal,
> > you can avoid race conditions too.  (This is what my programs do).
> 
> It's more than whether a signal is blocked or not, unfortunately. Lots of 
> applications will invoke sigwaitinfo() on whatever the current signal mask 
> is, which means you can't rely on sigaction to solve your problems. :-(

As Chris points out, allocating a signal by the scheme Jamie
describes is neccessary but not sufficient.  The problem Chris
ran into is that he allocated a signal fair and square, only to find
the application picking it up via sigwaitinfo()!
Yes, this is a bug in the application -- but it's interesting that this
bug only shows up when you try to integrate a new, well-behaved, library 
into the app.  It's a fragile part of the Unix API.  sigopen() is
a way for libraries to defend themselves against misuse of sigwaitinfo()
by big applications over which you have no control.

So sigopen() is a technological fix to a social problem, I guess.
- Dan