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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:50 EST