Re: and nicer too - Re: [PATCH] epoll more scalable than poll

[Davide Libenzi]

On Wed, 30 Oct 2002, Jamie Lokier wrote:

> John Gardiner Myers wrote:
> > I am uncomfortable with the way the epoll code adds its own set of
> > notification hooks into the socket and pipe code.  Much better would be
> > to extend the existing set of notification hooks, like the aio poll code
> > does.
>
> Fwiw, I agree with the above (I'm having a think about it).
>
> I also agree with criticisms that epoll should test and send an event
> on registration, but only _if_ the test is cheap.  Nothing to do with
> correctness (I like the edge semantics as they are), but because
> delivering one event is so infinitesimally low impact with epoll that
> it's preferable to doing a single speculative read/write/whatever.
>
> Regarding the effectiveness of the optimisation, I'd guess that quite
> a lot of incoming connections do not come with initial data in the
> short scheduling time after a SYN (unless it's on a LAN).  I don't
> know this for sure though.

Ok Jamie, try to explain me which kind of improvement this first drop will
bring. And also, how such first drop would not bring a "confusion" for the
user, letting him think that he can go sleeping event w/out having first
received EAGAIN. Isn't it better to say "you wait for events after EAGAIN",
instead of "you wait for events after EAGAIN but after accept/connect".
The cost of the test will be basically the cost of a ->poll(), that is
exactly the same cost of the very first read()/write() that you would do
by following the current API rule.

- Davide