On Tue, Dec 20, 2011 at 3:04 PM, Paddy Byers <paddy.by...@gmail.com> wrote: > This has been asked for before and rejected. > > This is what I'm doing, which works well: > > http://lists.schmorp.de/pipermail/libev/2011q4/001584.html
(Replying to libev mailing list so that Marc can see my reasons) I see. My case is a little different though: you're thinking about multiple event loops in a single thread while I'm thinking about one event loop per thread. I'm thinking about multiple eio contexts with each context having its own thread pool. This would be similar to how EV_MULTIPLICTY works in libev. The reasons why I have multiple threads are: 1. I want to make full use of all CPU cores. 2. All threads are mostly independent, but share one data structure. It's faster to query and to manipulate this data structure with locks and shared memory than to use message passing and multiple processes. 3. I want to minimize context switching overhead. Context switching between processes involves flushing the TLB while context switching between threads does not (at least on Linux). Manipulating a shared data structure through message passing *always* involves a context switch, even in the uncontended case, while mutexes do not impose such overhead in the uncontended case. - Hongli -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
