Messages in this thread | | | Date | Tue, 15 Oct 2002 15:33:27 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [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/
| |