[lkml]   [2002]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: and nicer too - Re: [PATCH] epoll more scalable than poll
    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

    > 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.


    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.026 / U:17.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site