Hello Sam, On 07/25/2010 03:12 AM, Sam Varshavchik wrote: > I'd like to propose adding the following to the current, somewhat terse, > description of POLLHUP: > > == > > For stream sockets, this indicates that the peer closed its side of the > connection. This does not necessarily imply that there's no more data to be > read from the socket. POLLHUP may be set even if some unread data remains in > the socket. Applications that need to process all data sent from their > socket peer should use read(2) to check for unread data if POLLHUP is set. > > == > > That's something I didn't know -- I still learn something new every day -- > When I get a POLLHUP I've assumed that it indicates an end-of-file > condition, but that's not apparently the case, and having this documented > would be helpful. Long after the fact... I added this text: [[ Note that when reading from a channel such as a pipe or a stream socket, this event merely indicates that the peer closed its end of the channel. Subsequent reads from the channel will return 0 (end of file) only after all outstanding data in the channel has been consumed. ]] And also made a similar change in epoll_ctl(2). Thanks for the report. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
