Thanks Nick. How do I enable the "common timeout" logic? Or is it enabled by default in 2.0.3-alphra?
On Mon, Nov 30, 2009 at 1:48 AM, Nick Mathewson <ni...@freehaven.net> wrote: > On Sun, Nov 29, 2009 at 11:18:19PM -0500, Donghua Xu wrote: >> Hi, >> >> Sorry if this is a stupid question. But I have not found a clear >> answer in the documentations. I am just beginning to look into using >> libevent for our project. We will need to schedule millions of timed >> events, and thousands of them may be triggered at the same time. So we >> have to use thread pool to handle all these events. Let's say we have >> 10 threads running at the same time, so how do I know which thread >> will the call-back function be running when an event is triggered? Is >> it always the thread that calls event_base_set() for the event? Or >> could it be some other thread? > > When you schedule an event, it will be run in the thread that is > running the loop for that event base. So if you say > > event_assign(event2, base99, ...); > > And later, you say > > event_base_dispatch(base99); > > Then the thread that called event_base_dispatch() for base99 will be > the one to run event2's callback. > > Note that Libevent 1.4.x does not provide thread-safety for access to > an event_base from another thread: if you want to be able to add or > remove an event from an event_base that another thread is using, > please check out the 2.0.x series. > > Note also that if you have millions of timer events scheduled (wow!), > Libevent's default min-heap timer implementation might not be as > fast as you want. The "common timeout" logic added in 2.0.3-alpha might > be a viable choice for this kind of scenario, if it applies to your > actual use-case. > > Right now Libevent has no built-in thread-pool support. Generally > speaking, if you want a thread-pool style structure with today's > Libevent, I think you have two basic options: > - Run an event_base loop in each thread, and try to assign events > to bases fairly > and/or > - Have the callback from each work-intensive event assign the > work to a worker thread rather than running it immediately. > though other people can probably add more info about what has worked > for them. > > (I'd like to get better thread pool support in a future version, but > as things stand, it is probably too big a feature for the 2.0.x > series. Maybe 2.1.x, if somebody wants to write it.) > > yrs, > -- > Nick > > > > > > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. > *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
