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

[Davide Libenzi]

On Mon, 14 Jul 2003, Jamie Lokier wrote:

> Davide Libenzi wrote:
> > Ouch, I definitely liked more the POLLHUP thing. It is not linked to epoll
> > at all.
>
> POLLRDONCE isn't linked to epoll - it's a valid hint for poll/select too.
>
> It means something different, i.e. you can't write:
>
> > 	if (events & EPOLLRDHUP) {
> > 		d->flags |= HANGUP;
> > 		schedule_removal(d);
> > 	}
>
> Be careful, because that isn't valid if there is urgent data.  You
> need to check POLLPRI too.  Granted urgent data is usually best ignored :)

I didn't want to code the whole application here, hope you understand ;)

> If fast hangup is a useful optimisation too, we should have both flags.
> (However calling read() doesn't seem like a great penalty for that).

Indeed. Hangup cases are a small fraction of std ones, so it has no sense
to optimize for them trying to avoid at all the read. And the name
READONCE seems to imply that you can't read(2) twice. I'd rather prefer
the RDHUP flag that tells me : There's an hungup condition for sure, and
you might also find some data since POLLIN is set.

- Davide