Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 13 Jul 2003 10:00:38 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [Patch][RFC] epoll and half closed TCP connections |
| |
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
- 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/
| ![\](/images/icornerr.gif) |