Re: A signal fairy tale

From: Daniel R. Kegel (
Date: Wed Jun 27 2001 - 22:04:41 EST

Christopher Smith <> wrote:

> Jamie Lokier <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:18 EST