![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 13:46 [from the cache] ©2003-2008 | |||||||||||||