lkml.org 
[lkml]   [2002]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    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/

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