Mark Mielke wrote:
> On Tue, Nov 19, 2002 at 12:49:16AM -0500, Grant Taylor wrote:
> > For example, sometimes TCP reads return EAGAIN when in fact they have
> > data. This seems to stem from the case where the signal is found
> > before the first segment copy (from tcp.c circa 1425, there's even a
> > handy FIXME note there). If you use epoll and get an EAGAIN, you have
> > no idea if it was a signal or a real empty socket unless you are also
> > very careful to notice when you got a signal during the read.
>
> I hope this isn't a stupid question: Why doesn't the code you speak of
> return EINTR instead of EAGAIN?
Mark's right, it should be EINTR. EAGAIN shouldn't break any
single-thread user state machines using poll/select, as a non-blocking
read is always allowed to return EAGAIN for any transient reason.
I'm not sure if EAGAIN can cause a poll() wakeup event to be missed.
If so, that would be a TCP bug that breaks epoll, and it would also
break some user state machines using poll/select, when there are
multiple processes waiting on a socket.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:27 EST