On Fri, Sep 08, 2006 at 10:18:11AM -0700, Scott Lamb wrote: > At a high level, I think it would require the basic poll algorithm to > be: > > lock > loop: > while there are events: > dequeue one > unlock > handle it > lock > if someThreadPolling: > condition wait > else: > someThreadPolling = true > poll for events > lock > fire condition > unlock > > so whatever thread happens to notice that it's out of events does a > poll, and the others can see the results immediately. But I haven't > addressed actually putting new fds into the poll array. I'm not sure > what the behavior there has to be. I admit it - this approach is > complicated.
Ah. I was approaching it from another angle (one thread per event loop, and the question being how to inject events and balance events into each event loop). I'd never want to touch the above scheme w/ a ten foot pole, mostly because one of the greatest benefits I enjoy with event-oriented programming is the lack of contention (i.e. not having to use a mutex everywhere). There are lots of scenarios where I might have multiple events outstanding, all related to a single context (TCP proxying, for instance). In the above design, I'd have to begin littering mutexes around my code. Relating those oustanding events to a shared event loop implicitly frees me from having to deal w/ this problem. When I use threads the only mutexes I want are the ones protecting malloc()/free(), and the handful of other similar global resources. > Anyway, I'm not suggesting adopting this without actual proof that > it's better. I need to blow the dust off my benchmark tools, but I'm > willing to put the effort into trying things out if I hear ideas I like. Fair enough. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
