Grant Taylor wrote:
> Meanwhile, in the more important caveat department (Dan, this will
> appeal to you), I found a while back that signals cause pain with
> epoll.
>
> 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.
> ...
> /* We need to check signals first, to get correct SIGURG
> * handling. FIXME: Need to check this doesnt impact 1003.1g
> * and move it down to the bottom of the loop
> */
> if (signal_pending(current)) {
> if (copied)
> break;
> copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
> break;
> }
eek! Thanks for noticing that!
Jamie wrote:
> 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.
I guess we should scour the sources looking for ways read() and write()
can return EAGAIN, and make sure that there is no chance this causes
a hang in user state machines that rely on epoll. (Sure would be nice
if the Stanford Checker was up to this kind of thing.)
- Dan
-
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:28 EST