Hello again!
On Tue, Nov 6, 2012 at 4:12 PM, Himanshu S <mail2himan...@gmail.com> wrote:
>
> On Tue, Nov 6, 2012 at 7:37 AM, Nick Mathewson <ni...@freehaven.net>wrote:
>
> Right now the best way to do what you have in mind is to consider *why*
>> you only want to read partial data and then read again after the next event
>> loop -- there's usually a better way to do whatever you're trying to
>> achieve.
>>
>
> The main reason for doing this is to avoid spending unfair amount of time
> on a single stream.
>
Has this turned out to be a problem for your code in practice? Libevent
already tries to round-robin its reads between multiple bufferevents by
limiting the number of bytes it will read for each pass through the event
loop. If you want, you can limit it even more by setting a read
high-watermark so that libevent won't fill up any input buffere on a
bufferevennt y more than the requested amount.
> But if there isn't, and you want to make sure your code works with
>> future versions of Libevent, your best bet is either to add a feature like
>> this in Libevent 2.1, or to create a separate event whose callback will
>> also run the bufferevent's callback, and activate that one.
>>
>> Is it true that the event_active() works only from a different thread? I
> see event_active() eventually calls event_callback_activate_nolock_() & it
> checks if the thread_id is different. So event if I create a separate event
> & call event_active() on that event, from the same thread, would it still
> work?
>
event_active() should work from any thread. But it won't actually get you
the behavior you want: it appears that you'd want the event's callback to
be invoked in the *next* iteration of the event loop, when in fact
event_active() (when you call it from within a callback) is allowed to make
the event active in the *current* itertion of the mainloop.
Libevent 2.1 has a notion of event_active_next() for scheduling an event to
become active in the next mainloop iteration; I wonder if it's closer to
what you need here. I don't know if it's exposed yet, but maybe it should
be if it's good for something.
> int
> event_callback_activate_nolock_(struct event_base *base,
> struct event_callback *evcb)
> {
>
> ...
>
> event_queue_insert_active(base, evcb);
>
> if (EVBASE_NEED_NOTIFY(base)) <-----
> evthread_notify_base(base);
>
> This "NEED_NOTIFY" business is only meaningful when the event loop is
running in another thread. To "notify" the loop means to activate an event
on it (via eventfd, a socketpair, or whatever), so that it will wake up and
process events. It doesn't need to happen when you're activating an event
from the thread in which the loop is running.
yrs,
--
Nick
