> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/