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
    On Tue, 15 Oct 2002, John Myers wrote:

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

    There're many ways to have /dev/epoll working in a threaded environment if
    you think about it, and no you don't need to have a single thread fetching
    events. You can have, if you really like threads, N fetching threads (
    working on N private /dev/epoll fds ), feeding M queues, polled by P
    service threads. If you like it ...




    - 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:2.249 / U:0.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site