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

[Davide Libenzi]

On Sun, 13 Jul 2003, Jamie Lokier wrote:

> > 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.
>
> Not sure exactly how you're thinking with that last sentence.

Brain farting, delete it ;) This is a nice page about POLLHUP treatment :

http://www.greenend.org.uk/rjk/2001/06/poll.html

> At present, it's impossible for socket code to return POLLHUP only to
> apps which are waiting on POLLOUT - because POLLHUP is not maskable in
> sys_poll's API.  Therefore sockets return POLLHUP only if they are
> closed in both directions.
>
> There is no way for a socket to return a HUP condition for someone who
> is waiting only to write, but fortunately that doesn't matter :)

Yes, this could be improved though. If we could only pass our event
interest mask to f_op->poll() the function will be able to register it
inside the wait queue structure and release only waiters that matches the
available condition.

> (*) There aren't that many places which set POLLHUP; they divide into:
> sockets, ttys, SCSI-generic and PPP.  The latter two are not important
> as they don't do half-close.
>
>    __The critical thing with POLL_RDHUP is that it is set if read() would
>    return EOF after returning data.__
>
>    If this condition isn't met, than an app which is using POLL_RDHUP to
>    optimise performance using epoll will hang occasionally.
>
> Sockets are important: TCP is not the only thing to support
> half-closing.  If an app is waiting for POLLRDHUP, and it doesn't know
> what kind of socket it has been given (e.g. AF_UNIX), the network
> stack had better return POLL_RDHUP when there's an EOF pending.
>
> So we'd better add POLLRDHUP to all the socket types which do
> half-closing.  For the rest, no change is required as POLLHUP is
> non-maskable :)  (So apps should always say "if (events &
> (POLLHUP|POLLRDHUP)) check_for_eof()").
>
> And ttys?  They are problematic, because ttys can return EOF _after_
> returning data without closing (and without being hung-up).  An epoll
> loop which is reading a tty (and isn't programmed specially for a tty)
> _must_ receive POLLRDHUP when the EOF is pending, else it may hang.
>
> In other words, POLLRDHUP is the wrong name: the correct name is
> POLLRDEOF.

Please replace 'it may hung' with 'it may hung if it is using the read()
return bytes check trick' ;)

- Davide