Messages in this thread | | | Date | Tue, 19 Nov 2002 15:24:36 +0000 | From | Jamie Lokier <> | Subject | Re: [rfc] epoll interface change and glibc bits ... |
| |
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/
| |