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

[Davide Libenzi]

On Wed, 30 Oct 2002, John Gardiner Myers wrote:

> You posted code which you claimed was "even more cleaner and simmetric"
> (sic) because it fell through to the do_use_fd() code instead of putting
> the do_use_fd() code in an else clause.  A callback scheme is akin to
> the if/else structure.  To adapt the first code to a callback scheme,
> the accept callback has to somehow arrange to call the do_use_fd()
> callback before returning to the event loop.  This requirement is subtle
> and asymmetric.

A callback scheme can be _trivially_ implemented use the current epoll.
I'm sure you know exactly how to do it, so I'm not spending more time
explaining it to you.

> Basically, you spawn off another coroutine.  That complicates the "fall
> through to do_use_fd()" logic in the first code by requiring an external
> facility not required by the second code.  The second code could simply
> have the accept code loop until EAGAIN.

No it does not, you always fall through do_use_fd(). It's that simple.

> Epoll creates a new callback mechanism and plugs into this new callback
> mechansim.  It adds a new set of notification hooks which feed into this
> new callback mechansim.  The end result is that there is one set of
> notification hooks for classic poll and another set for epoll.  When
> epoll is not being used, the poll and socket code makes an additional
> set of checks to see that nobody has registered interest through the new
> callback mechanism.

Where epoll hooks has nothing to do with ->f_po->poll()

> > It fits _exactly_
> >the rt-signal hooks. One of the design goals for me was to add almost
> >nothing on the main path. You can lookup here for a quick compare between
> >aio poll and epoll for a test where events delivery efficency does matter
> >( pipetest ) :
> >
> This is a comparison of the cost of using epoll to the cost of using aio
> in one particular situation.  It is irrelevant to the point I was making.

See, I believe numbers talks. And it does make a pretty clear point
indeed.

> My understanding of the efficiency of the epoll event notification
> subsystem is:
>
> 1) Unlike the current aio poll, it amortizes the cost of interest
> registration/deregistration across multiple events for a given connection.

Yep

> 2) It declares multithreaded use out of scope, making optimizations that
> are only appropriate for use by single threaded callers.

It's not single threaded. It can be used in multithreaded environment if
the one that code the app has a minimal idea of what he's doing. Like
everything else. You cannot use a FILE* wildly sharing it randomly inside
a multithreaded app, and expecting to receive coherent results. Like 95%
of the APIs. Can those APIs be used in a multithreaded environment ? You bet,
with care, like everything that uses freakin' threads.

- Davide