Re: [Patch][RFC] epoll and half closed TCP connections

[Davide Libenzi]

On Sun, 13 Jul 2003, Jamie Lokier wrote:

> David S. Miller wrote:
> > Alexey, they seem to want to add some kind of POLLRDHUP thing,
> > comments wrt. TCP and elsewhere in the networking?  See below...
>
> POLLHUP is a mess.  It means different things according to the type of
> fd, precisely because it is considered an unmaskeable event for the
> poll() API so the standard meaning isn't useful for sockets.  (See the
> comments in tcp_poll()).
>
> POLLRDHUP makes sense because it could actually have a well-defined
> meaning: set iff reading the fd would return EOF.
>
> However, if a program is waiting on POLLRDHUP, you don't want the
> program to have to say "if this fd is a TCP socket then listen for
> POLLRDHUP else if this fd is another kind of socket call read to
> detect EOF else listen for POLLHUP".  Programs have enough
> version-specific special cases as it is.
>
> So I suggest:
>
>   - Everywhere that POLLHUP is currently set in a driver, socket etc.
>     it should set POLLRDHUP|POLLHUP - unless it specifically knows
>     about POLLRDHUP as in TCP (and presumably UDP, SCTP etc).

Returning POLLHUP to a caller waiting for POLLIN might break existing code
IMHO. After ppl reporting the O_RDONLY|O_TRUNC case I'm inclined to expect
everything from existing apps ;) POLLHUP should be returned to apps
waiting for POLLOUT while POLLRDHUP to ones for POLLIN.

- Davide