lkml.org 
[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A signal fairy tale
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
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.033 / U:16.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site