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

[Jamie Lokier <jamie@shareable.org>]

Davide Libenzi wrote:
> 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.

It's not a bad idea.

> > 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.
> 
> Please replace 'it may hung' with 'it may hung if it is using the read()
> return bytes check trick' ;)

Sure - but take an app that is normally using TCP sockets and give it
an AF_UNIX socket..  Something as general as the event loop
_shouldn't_ have to depend on that subtlety.

Ok that's avoidable, but it's a trap.  It would be nice to get a flag
that doesn't have a caveat in the manual saying "this flag only works
(at present) on TCP sockets in kernels >= 2.5.76.  Take care not to
use the optimisation for any other kind of fd including other sockets,
as it will break your app...".  That's not the sort of thing I want to
see in the epoll manual page :)

Anyway, there is a correct answer and I have made the patch so wait
for next mail... :)

-- Jamie