lkml.org 
[lkml]   [2002]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] async poll for 2.5
    Dan Kegel wrote:

    >The most effective way to use something like /dev/epoll in a
    >multithreaded
    >program might be to have one thread call "get next batch of events",
    >then divvy up the events across multiple threads.
    >
    That is a tautology. As /dev/epoll is inherently a single threaded
    interface, of course the most effective way for a multithreaded program
    to use it is to have one thread call it then divvy up the events.
    That's the *only* way a multithreaded program can deal with a single
    threaded interface.

    The cost to divvy up the events can be substantial, not the mention the
    cost of funneling them all through a single CPU. This cost can easily
    be greater than what one saves by combining events. io_getevents() is a
    great model for divvying events across multiple threads, the poll
    facility should work with that model.

    The solution for optimizing the amount of event collapsing is to
    implement concurrency control.

    >Once you allow that, it's easy to handle the
    >condition you're worried about by generating a spurious readiness
    >indication when registering a fd. That's what I do in my wrapper
    >library.
    >
    This is a workaround. You are adding additional code and complexity to
    the caller in order to deal with a deficiency in the interface. This
    has several problems:

    Someone writing to the /dev/epoll interface needs to know that they need
    to write such workaround code. If they don't know to write the code or
    if they make an error in the workaround code, it is still likely that
    the program will pass testing. What will result are intermittent, hard
    to diagnose failures in production.

    User space does not have the information to address this as well as the
    kernel can. As a result, the workaround requires more processing in the
    common, non racy case.

    The kernel can clearly handle this situation better than user space. It
    can do the necessary checks while it is still holding the necessary
    locks. It is less error prone to handle the situation in the kernel.
    The logic clearly belongs in the kernel.

    >Also, because /dev/epoll and friends are single-shot notifications of
    >*changes* in readiness, there is little reason to register interest in
    >this or that event, and change that interest over time; instead,
    >apps should simply register interest in any event they might ever
    >be interested in.
    >
    You're making assumptions about the structure and flow of an
    application. Sometimes when an application stops having interest in
    this or that event, it needs to free/invalidate the context associated
    with that event.

    So that's fine as a strategy for amortizing the cost of
    registration/deregistration, but it isn't universally applicable.

    [unhandled content-type:application/x-pkcs7-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:4.681 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site