wait()/alarm() race condition

[Brian Buchanan]

On Sun, 30 Mar 2003, [ISO-8859-1] Mikko Työläjärvi wrote:

> On Sun, 30 Mar 2003, Sean Hamilton wrote:
>
> > Dan Nelson wrote:
> > | Just make sure your signal handler has the SA_RESTART flag unset
> > | (either via siginterrupt() if the handler was installed with signal(),
> > | or directly if the signal was installed with sigaction() ), and the
> > | signal will interrupt the wait() call.
> >
> > Er, I think you've missed my problem. Or I'm not getting your solution.
> >
> > I'm concerned about this order of events:
> >
> > - alarm()
> > - wait() returns successfully
> > - if (alarmed...) [false]
> > - SIGALRM is delivered, alarmed = true
> > - loop
> > - wait() waits indefinitely
> >
> > This is incredibly unlikely to ever happen, but it's irritating me somewhat
> > that the code isn't airtight. Bad design. Surely there is some atomic means
> > of setting a timeout on a system call.
>
> My stock solution to this kind of problem is to turn those pesky
> signals into I/O and use an old fashioned select() loop to handle
> them; create a pipe(2), let signal handlers write one-byte "messages"
> (the signal number) into the pipe and then use select() to dequeue the
> events (signals) from the pipe.
>
> Select() has a timeout parameter you can play with to your hearts
> content, and provided you don't overflow the pipe, no events will
> get lost.  You'd have to install a hander for SIGCHLD, of course.

Or how about kqueue(2) with EVFILT_SIGNAL.  That would seem to be a more
elegant solution.  No signal handlers or alarm() required.

-Brian

-- 
Brian Buchanan, CISSP                                         bwb at holo.org
--------------------------------------------------------------------------
FreeBSD - The Power to Serve!                       http://www.freebsd.org