Re: [Libevent-users] Multithreaded behavior
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
Re: [Libevent-users] Multithreaded behavior
On Fri, Sep 08, 2006 at 04:17:20PM -0700, Scott Lamb wrote: On Sep 8, 2006, at 12:13 PM, William Ahern wrote: 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). Like the first thing I described? Have you actually done this and had any luck with it? I suppose I could give it a go, at least for a simple balancing scheme. What I've done in an MTA is use descriptor passing. A master process listens for connections and than sends them to it's children. I keep a tree of children, ordered by number of outstanding connections. When a child loses a connection it sends a message down a pipe so I can decrement it's connection count. But that's sort of heavy weight; ultimately I liked the idea because it provided robustness. I would like to try this scheme in a single-process, multiple thread environment. Each event loop could have an outstanding event listening on a pipe (just like the signal pipe in libevent). The thread accepting connections would select a thread to hand-off a connection and dump it into a queue, then signal that thread's event pipe. Actually, this is how I had assumed everybody else was doing it after I saw the event_base support go into the library. And also the source of my poll on a mutex, because using a pipe for this also always seemed a little heavy weight. Though, I've never benchmarked so I have no right ;) ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
