On Thu, Sep 07, 2006 at 11:29:50PM -0700, Scott Lamb wrote: > I think libevent's current multithreaded behavior is not terribly > useful: > > 1. You can't safely share a single event_base among a pool of > threads. This is actually what I'd like to do with threads, > especially now that four-core systems are becoming cheap. (My SSL > proxy should be able to put those extra cores to use.) > It's...tricky...to get right, though.
Why would you ever want to do this? I mean, in one sense it could simplify some multi-threaded designs. The complexity it adds, however, hardly seems worth it compared to how simple this could be done on a per-application basis using the existing API. Actually, to get this right from both an aesthetic as well as efficiency perspective would require, I think, libevent to be able to poll on both a condition variable as well as traditional descriptor objects. Maybe the underlying capability could feasibly be added to kqueue's.... Nonetheless it's a pretty far fetched proposition. <snip> > I'm not sure what the ideal thread behavior would be, though, much > less how to achieve it in a backward-compatible way. Opinions? > Personally, ideal thread behavior is pretty close to the existing state of things. Could you be more specific on the ideas you have which involve threads sharing the same event object (disregarding my opening sarcasm ;) _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
