Re: POLLRDONCE optimisation for epoll users (was: epoll and half closed TCP connections)

[Jamie Lokier <jamie@shareable.org>]

Davide Libenzi wrote:
> > > > 	(a) fd isn't a socket
> > > > 	(b) fd isn't a TCP socket
> > > > 	(c) kernel version <= 2.5.75
> > > > 	(d) SO_RCVLOWAT < s
> > > > 	(e) there is urgent data with OOBINLINE (I think)
> >
> > > Jamie, did you smoke that stuff again ? :)
> > > With Eric patch in the proper places it is just fine. You just make
> > > f_op->poll() to report the extra flag other that POLLIN. What's the problem ?
> >
> > The problem in cases (a)-(e) is your loop will call read() just once
> > when it needs to call read() until it sees EAGAIN.
> >
> > What's wrong is the behaviour of your program when the extra flag
> > _isn't_ set.
> 
> Jamie, the loop will call read(2) until data is available. With the trick
> of checking the returned number of bytes you can avoid the extra EAGAIN
> read(2). That's the point of the read(2) trick.

That _only_ works if none of those conditions (a)-(e) applies.
Otherwise, short reads are possible when there is more to come.

Sure, if you're willing to assert that the program is running on
kernel >= 2.5.76, all its fds are for sure TCP sockets and you added
the POLLPRI check, then yes it's fine.

I think mine is better because it works always, and you are free to
code the optimisation in any programs, libraries etc.

> The final check for RDHUP will tell that it has no more to wait for
> POLLINs since there's no more someone sending.

Sure, _that_ check is fine.

-- Jamie