Re: [Libevent-users] event_base_loop: wait for events to be added by other threads?

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Dec 3, 2010 at 4:28 PM, Evan Jones <evanj@xxxxxxx> wrote:
 [...]
>> 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().

Hm.  I think that's reasonable.

>> 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?

I'm not sure; I can't tell what it's the right choice for, but that
doesn't mean it's totally nonsensical.  The semantics are more or less
the same as plain old NONBLOCK fwict.  A quick google codesearch shows
that we're doing it in our unit tests, and bunches of other programs
are doing it too.  Breaking them gratuitously would be a bad thing.

yrs,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.