On Fri, Dec 3, 2010 at 4:28 PM, Evan Jones <ev...@mit.edu> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
