Re: [rfc] epoll interface change and glibc bits ...

[Dan Kegel <dank@kegel.com>]

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