Re: select()

[Roland McGrath]

> This is not possible!!! msgerr can not be EINTR at this point, otherwise
> the while() loop should have been terminated!

As Mark said, probably `msgerr' (while is only live in that one line) is
just assigned to %eax and that is used for something else later.  Always
check with `i ad msgerr' and look the disassembly nearby where something is
suspicious.

So, pfinet returned EINTR.  It is allowed to do this spuriously, and select
is supposed to deal (but doesn't).  But probably it is doing it because
there is some other client thread using the same socket that did
interrupt_operation.  The problem is that select isn't using the
interruptible-RPC infrastructure stuff in the signal thread, and so it
doesn't know whether it actually just got a signal or whether that signal
had SA_RESTART set.

> Another question is why pfinet returns EINTR.  It seems to happen if I
> have two connections, eg, I am downloading with apt-get, and then start
> lynx with a page.  This quickly and reproducably leads to an EINTR from
> pfinet.  Is this correct behaviour?  What does interrupting mean for
> pfinet?

This is worth looking into.  The only time EINTR should be returned is
after interrupt_operation was called on that socket.

> Oh, and a timeout of 0 doesn't work anyway, as we found out earlier.  Should
> this code be changed to use the minimal timeout?

In that particular use, timeout 0 does what is wanted.  If other io_select
replies from other ports have come back already, they will be collected.
That's all we want, since we already have one reply.  The problem with
timeout 0 is the first time, when it can return immediately before the io
servers have had a chance to receive the io_select requests.