On Fri, Aug 27, 2010 at 10:54 AM, Gilad Benjamini <gi...@altornetworks.com> wrote: > > I read the documentation on loopbreak and loopexit in both > http://www.wangafu.net/~nickm/libevent-book/ and the header file and I still > don't fully understand the details. > > "vent_base_loopbreak ... differs from event_base_loopexit(base, NULL) in > that if the event_base is currently processing any active events, it will > exit immediately after finishing the one it's currently processing." > > The sentence above initially uses "currently processing" to refer to events > in the plural form, and then uses the same phrase to refer to event in the > singular form. What does "currently processing" actually mean ? How is it > different from an "active event" ?
That's my fault. I'll try to rephrase. By an active event, I meant one which has triggered and whose callback needs to be called. [I see this explanation in the docstring for the activequeues but unless I'm missing it, not anywhere prominent in the documentation. And unfortunately, the main doxygen page seems to use a contradictory meaning in the phrase "The event structure must remain allocated as long as it is active".] event_base_loopbreak(evbase) will cause a running event_base_loop(evbase) to return without calling any additional callbacks. In constrast, event_base_loopexit(evbase, NULL) will cause a running event_base_loop(evbase) to return after calling the callbacks of all active events (but without blocking again). [I'm not being precise about the behavior when multiple threads are interacting with the same event_base. Can you do that with libevent2? I think there have been changes regarding threading, but I haven't had time to follow the details.] I added event_base_loopbreak so that wrappers in languages that implement exceptions could use it to throw exceptions from a callback all the way through to the caller of event_base_loop. pyevent is doing this now with some really awkward manipulations of internal variables: http://pyevent.googlecode.com/svn/trunk/pyevent/event.pyx def __simple_callback(self, short evtype): cdef extern int event_gotsig cdef extern int (*event_sigcb)() global __event_exc try: if self.callback(*self.args) != None: if self.tv.tv_sec or self.tv.tv_usec: event_add(&self.ev, &self.tv) else: event_add(&self.ev, NULL) except: __event_exc = sys.exc_info() event_sigcb = __event_sigcb event_gotsig = 1 # XXX - account for event.signal() EV_PERSIST if not (evtype & EV_SIGNAL) and \ not event_pending(&self.ev, EV_READ|EV_WRITE|EV_SIGNAL|EV_TIMEOUT, NULL): Py_DECREF(self) It'd make sense to switch pyevent after it drops support for any libevent version prior to event_base_loopbreak's introduction. Probably when it adopts the libevent2 API. > > The sentence also implies that this is the ONLY difference between the > functions, while in practice the delay factor also seems to be a > differentiator. delay wouldn't make much sense with event_base_loopbreak. > > Am I missing something ? > > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. -- Scott Lamb <http://www.slamb.org/> *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
