> On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
> >
> > > Now, next time around the loop, we get a notification for an event
> > > when there is no data to read. The application now must be prepared
> > > to handle this case (meaning no blocking read() calls can be used).
> > > --
> > > Jonathan
> >
> > If the programmer never wants to block in a read call, he
> > should never do a
> > blocking read anyway. There's no standard that requires
> > readability at time
> > X to imply readability at time X+1.
>
> Quite true on the surface. But taking that statement at face value
> implies that it is okay for poll() to return POLLIN on a descriptor
> even if there is no data to be read. I don't think this is the intention.
Never mind what it implies. Just stick to what it says. :)
In my opinion, it's perfectly reasonable for an implementation to show
POLLIN on a call to poll() and then later block in read(). As far as I know
no implementation does this, but no standard prevents an implementation
from, for example, swapping out received TCP to disk if it's not retrieved
and blocking later when you ask for the data until it can get the data back.
I would even argue that it's possible for an implementation to decide that
a connection had errored (for example, due to a timeout) and signalling
POLLIN. Then before you call 'read', it gets a packet and decides that the
connection is actually fine and so blocks in 'read'. This wouldn't seem
possible in TCP, but it's possible to imagine protocols where it's sensible
to do. And again, as far as I know, no standard prohibits it.
If a programmer does not ever wish to block under any circumstances, it's
his obligation to communicate this desire to the implementation. Otherwise,
the implementation can block if it doesn't have data or an error available
at the instant 'read' is called, regardless of what it may have known or
done in the past. It's also just generally good programming practice. There
was a time when many operating systems had bugs that caused 'select loop'
type applications to hang if they didn't set all their descriptors
non-blocking.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:17 EST