Jamie wrote:
> Daniel R. Kegel wrote:
> > 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()!
>
> 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?
I think your assumption is correct. The problem is that the
application in question (Sun's JDK 1.4 beta) does something like this:
sigprocmask(0, NULL, &oldset);
sigwaitinfo(&oldset, &info);
So even though Chris did set the handler for his signal to non-SIG_DFL,
the application didn't care, and sucked all his signal notifications
away from him.
> > 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.
I didn't mean to require any library to change at all. This is
an optional thing; a library can use this technique if it wants to
insulate itself from badly behaved applications.
> Sometimes you actually do need SIGRTxxx signals to be delivered using
> signal handlers!
No objection there, I agree.
> 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.
I have no objection to sigopen() taking a sigset_t *.
> 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().
sigopen() essentially installs a special signal handler (say, SIG_OPEN).
If sigaction() can override that, it should probably close the file descriptor, too.
I can buy that, perhaps, even though it makes libraries using sigopen()
somewhat more vulnerable to poorly behaved applications. I think the
present application doesn't misbehave badly enough that it would try to
install a signal handler over Chris's.
> However, it would be ok to require a flag SA_SIGOPEN to sigaction() to
> prevent it from returning EBUSY.
That'd be ok.
Another issue someone raised:
> would read() on this fd require the kernel to copy every byte of the siginfo_t?
IMHO no; read() would leave undefined any bytes that would not have been set by
sigwaitinfo(). The kernel could set them to zero or leave them untouched,
as desired.
Another issue:
AFAIK, there's no 'read with a timeout' system call for file descriptors, so
if you needed the equivalent of sigtimedwait(),
you might end up doing a select on the sigopen fd, which is an extra
system call. (I wish Posix had invented sigopen() and readtimedwait() instead of
sigtimedwait...)
- 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/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:20 EST