Re: A signal fairy tale

[Daniel R. Kegel]

Jamie wrote:
> 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?
 
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