Re: Linux-2.1.54..

Marty Leisner (leisner@sdsp.mc.xerox.com)
Tue, 9 Sep 1997 12:03:37 PDT

> > Erm.. look harder Linus
> >
> > > for (;;) {
> > > retval = select();
> > > .. act on retval ..
> > > if (alarm)
> > > handle timeout
> > > }
> >
> > If the alarm occurs after the select completes and the if checks but before
> > the next select the program will sleep until the next network event. Its
> > things like that which I avoided ... The only alternative way is to use
> > sigsetjmp/siglongjmp which is _horrible_
>
> It seems to me that you can know, with portability, whether the
> timeout ocurred in the select() or not: test for (retval == -1) &&
> (errno == EINTR). What's the problem?
>

Actually, this points to one of the problems with select...

EINTR does not mean we alarmed...what if other signals are enable
(SIGIO? SIGUSR?)

Even playing with signal masks, you have race conditions
(i.e. signals can sneak in between:

unmask
select
mask

The "tried and true" Unix way to solve this problem is: (I thought
this was really clever, I would have never contrived it myself ;-))
make a pipe
have the alarm signal handler write a byte to the pipe
we add the read side of the pipe to our fdmask for select
if we come out of select with this fd ready, we know we alarmed.

Posix 1003.1g has another call which adds a signal mask to select
(i.e.
mask alarm
pselect(??, unmask alarm) (I think its called pselect)
--->>> at this point alarm is still masked.

(I've read this in reviewing Rich Steven's new book,
I don't have the spec in front of me.

-- 
marty
leisner@sdsp.mc.xerox.com  
The Feynman problem solving Algorithm
        1) Write down the problem
        2) Think real hard
        3) Write down the answer
                Murray Gel-mann in the NY Times