Re: [Libevent-users] Threading concerns

[Donghua Xu <donghua@xxxxxxxxx>]

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 <nickm@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.