Re: [Libevent-users] loopbreak vs. loopexit

[Scott Lamb <slamb@xxxxxxxxx>]

On Fri, Aug 27, 2010 at 10:54 AM, Gilad Benjamini
<gilad@xxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.



--
Scott Lamb <http://www.slamb.org/>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.