Re: A signal fairy tale

[Jamie Lokier]

Daniel R. Kegel wrote:
> Christopher Smith <[e-mail]> wrote:
> > Jamie Lokier <[e-mail]> 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()!

I check that the handler is not SIG_DFL, but perhaps my assumption that
any sigwaitinfo() user of a signal would set SA_SIGINFO and set the
handler to non-SIG_DFL is mistaken?

> 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.

Requiring all libraries to use the sigopen() as you specified it just
isn't going to work, because you would have to make big changes to the
libraries.

Sometimes you actually do need SIGRTxxx signals to be delivered using
signal handlers!

Also as it was specified, you are reduced to reading one type of signal
at a time, or using select().  Often you wish to check several signals.
For example, in my programs sigwaitinfo() calls check for SIGIO, SIGURG
and SIGRTxxx at least.  Therefore siginfo(), if implemented, should take
a sigset_t, not a signal number.

The problem of when you actually want to receive an allocated signal
through a handler is, IMHO, best solved by permitting sigaction() and
signal delivery on signals that have been opened with sigopen().

However, it would be ok to require a flag SA_SIGOPEN to sigaction() to
prevent it from returning EBUSY.

:-)
-- Jamie