[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] event_active bug?



Hi,

thanks for your reply. You understood well. I used both flags EVLOOP_ONCE  and EVLOOP_NONBLOCK while creating event_base. I was already able to fix it with the timer, or file descriptor and it works just as I want. As I said I was just surprised, that it works differently with event_active function and timer/fd solution (both makes event active all the time).

Thanks for your explanation!
harnen

2011/5/3 Nick Mathewson <nickm@xxxxxxxxxxxxx>
On Fri, Apr 29, 2011 at 5:43 AM, Michał Król <mharnen@xxxxxxxxx> wrote:
> Hi,
>
> I had some problems using event_active() function, and as I'm not sure
> weather it's a bug or not I've decided to write about it.
>
> I'm using two event bases, sender_base and feeder_base. sender_base runs as
> a main program loop using event_dispatch(). If there is nothing to send it
> calls event_base_loop() on feeder_base which fills the buffer (with events
> reading from files which(events) are all the time active).
> So in feeder_base there are many all the time pending events and there are
> invoked one by one when event_base_loop() is called.
>
> It worked perfectly fine unless I've decided to add to the feeder_base event
> which invokes itself by event_active and not by file descriptor + EV_READ.
> This event was filling the buffer and then rescheduling itself calling
> event_active(). I've expected that after calling event_active event will be
> just scheduled as pending and invoked during next call of event_base_loop().
> But from this time it was invoking itself infinitely within one loop of
> feeder_base. I was able to override this problem by opening random file
> (like /dev/zero) and invoking this event based on EV_READ and not by
> event_active. Anyway I'm just not sure if event_active is supposed to work
> like this or it's kind of a bug, so I've decided to write about it.
>
> I know my architecture is a bit messy, but I hope my description is clear
> enough.

Hi!  I've tried reading your explanation but I'm afraid I'm unclear on
what you mean, so if I have it wrong below, please let me know what
you really meant.

I think you're saying that you're calling event_base_loop() with the
EVLOOP_ONCE or EVLOOP_NONBLOCK flag set, and you're calling
event_active() on an event from inside an event callback.  You want
the event_active() to schedule the event's callback to run the *next*
time you call event_base_loop(), but instead it is scheduling it for
*this* iteration.

Question 1: Is it a bug?  (Skip this if you just want your program to work.)

According to the documentation, I think the current behavior is
allowed by EVLOOP_ONCE, where the doxygen says: "Block until we have
an active event, then exit once all active events have had their
callbacks run" and the book says "wait until some events become
active, then run active events until there are no more to run, then
return."

EVLOOP_NONBLOCK is murkier: the doxygen says "Do not block: see which
events are ready now, run the callbacks [of the] highest-priority
ones, then exit" and the book says "check whether any events are ready
to trigger immediately, and run their callbacks if so."  The former is
ungrammatical and missing some words (I just fixed it in git).  Both
are unclear as to whether events that are made active while the other
events' callbacks are running should get their callbacks invoked
during this event_base_loop() or not.  I should try to clarify this;
I'd welcome patches to the documentation and/or the book to make
either more accurate.

The pseudocode in the book still looks right to me, but it's a bit
late here and I could be missing something.

Question 2: Ignoring whether it's a bug, what's the best way to do
what you want?

If you want the event activated on the next time through the loop and
absolutely not this time, I'd consider an timeout event with a
duration of 0.

hoping this helps,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.