Re: POLLRDONCE optimisation for epoll users (was: epoll and half

[Davide Libenzi]

On Mon, 14 Jul 2003, Jamie Lokier wrote:

> Davide Libenzi wrote:
> > > (d) SO_RCVLOWAT < s
> >
> > This does not apply with non-blocking fds.
>
> Look at the line "if (copied >= target)" in tcp_recvmsg.

Look at this :

	timeo = sock_rcvtimeo(sk, nonblock);

;)

>
> > > (e) there is urgent data with OOBINLINE (I think)
> >
> > You obviously need an EPOLLPRI check in your read handling routine if you
> > app is expecting urgent data.
>
> Normal behaviour is for urgent data to be discarded, I believe.  Now
> if someone sends it to you, you'll end up with the socket stalling
> with pending data in the buffers.  Not saying whether you care, it's
> just a difference of behaviour to be noted and a potential DOS
> (filling socket buffers which app doesn't know to empty).

Yes, with OOBINLINE you need to take care of EPOLLPRI if you want to use
the read(2) trick. The OOB virtually break the read.

> > On Mon, 14 Jul 2003, Jamie Lokier wrote:
> >
> > > (a) fd isn't a socket
> > > (b) fd isn't a TCP socket
> >
> > Jamie, libraries, like for example libevent, are completely generic indeed.
> > They fetch events and they call the associated callback. You obviously
> > know inside your callback which kind of fd you working on.
>
> I disagree - inside a stream parser callback (e.g. XML transcoder) I
> prefer to _not_ know the difference between pipe, file, tty and socket
> that I am reading.

These are streams and you can use the read(2) trick w/out problems. I
don't think you want to mount your XML parser over UDP.

> > > (c) kernel version <= 2.5.75
> >
> > Obviously, POLLRDHUP is not yet inside the kernel :)
>
> Quite.  When you write an app that uses it and the read(2) trick
> you'll see the bug which Eric brought up :)
>
> I'm saying there's a way to write an app which can use the read(2)
> trick, yet which does _not_ hang on older kernels.  Hence is robust.

How, if you do not change the kernel by making it returning an extra flag ?

- Davide