On Dec 3, 2010, at 15:47 , Nick Mathewson wrote:
A quick heads-up here that you'll want to know: there's a bug in 2.0.9-rc and earlier where activating an event from another thread doesn't wake up the loop immediately. It should be fixed in 2.0.10; see commit 5beeec9d43cb.
Yeah, I saw that one already thankfully.
Wow, good timing. I actually coded up an example patch to try to do this earlier this week; have a look at branch "21_evloop_emptyok" in my github repository [git://github.com/nmathewson/Libevent.git] and see if it looks okay to you. I don't like the EMPTYOK name, but the rest of it seemed ok.
Oops! There goes an hour or two of my life. Your patch is basically equivalent to mine, except that I verify that the event_base has locks enabled, since otherwise the EMPTYOK option doesn't make sense. If EMPTYOK is passed without locks, I call event_err().
ONCE means wait till at least one non-internal callback is activated, then to run until there are no active callbacks. EMPTYOK|ONCE means wait till at least one non-internal callback is activated, then to run until there are no active callbacks, EVEN IF we didn't start with any pending events. NONBLOCK means to check events and run user callbacks until no more pending events want to be activated. EMPTYOK|NONBLOCK means to check events and run user callbacks until no more pending events want to be activated, EVEN IF we didn't start with any pending events.
This seems like a good interpretation, and makes sense now that I think about it.
ONCE|NONBLOCK doesn't seem reasonable to me atm.
Adding an event_err() for that combination might make sense then? Evan -- Evan Jones http://evanjones.ca/ *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
