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 <ni...@freehaven.net> > 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. >
