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

From: Davide Libenzi <davidel@xmailserver.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: "David S. Miller" <davem@redhat.com>,
	Eric Varsanyi <e0206@foo21.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kuznet@ms2.inr.ac.ru
Subject: Re: POLLRDONCE optimisation for epoll users (was: epoll and half closed TCP connections)
Date: Sun, 13 Jul 2003 20:21:49 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.55.0307132018200.15022@bigblue.dev.mcafeelabs.com> (raw)
In-Reply-To: <20030714031614.GD23110@mail.jlokier.co.uk>

On Mon, 14 Jul 2003, Jamie Lokier wrote:

> Davide Libenzi wrote:
> > > > Where this will break by using a POLLRDHUP ?
> > >
> > > It will break if
> > >
> > > 	(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. The final check for RDHUP
will tell that it has no more to wait for POLLINs since there's no more
someone sending.

- Davide