>> there's no SELECT_ERR anymore [...] the error will be reported when the FD will be read/written
>
> I don't think this is a good idea, particularly during this early stage.
> This assumption might be valid for select() but not for poll() and epoll() where (POLLERR | POLLHUP | POLLNVAL) is an alias for "connection lost", and that's an event which both Twisted and Tornado take into account and treat differently than a pure "read" event.

POLLERR and POLLNVAL semantics can be really different from
"connection lost", so this mapping sounds wrong. The actual error
(which may be ECONNRESET, but also EBADF, ENOBUFS...) will be raised
upon the next call to read()/write(), or can be retrieved through
getsockopt(SO_ERROR).

Also, that's exactly what the Linux kernel does for select():
http://lxr.free-electrons.com/source/fs/select.c#L381
POLLHUP is mapped to the read-set, POLLERR both to the read and write set.

This means that "connection lost" could never be returned on platforms
where the select() syscall is used, which could lead to subtle
portability problems.

But I'm definitely open on this (I've based the behavior on libevent
and Java, FWIW).

>> the exceptions set isn't passed to select() anymore: exception events (like OOB) are already reported in the read or write sets
>
> That's true only if SO_OOBINLINE has been pre-emptively set against the socket.
> It might be ok to ignore select()'s exceptional events anyway though.

Thanks, I didn't know: since the POSIX man pages was rather evasive on
this, I checked the Linux kernel source code, but apparently it's
non-standard. If we do ignore OOB in select(), then we probably also
want to suppress POLLPRI|EPOLLPRI, no?