On Fri, Apr 29, 2011 at 5:43 AM, Michał Król <mhar...@gmail.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
