epoll interface change and glibc bits ...

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;
		}

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.