On Tue, Apr 10, 2012 at 7:21 PM, Nir Soffer <nir...@gmail.com> wrote: > > On Apr 10, 2012, at 6:15 PM, Nick Mathewson wrote: > >> And there's a third way for libevent to see a big jump forward in >> time: if the program calls event_base_loop() sporadically, it is free >> to wait as long as it wants between invocations. >> >> So, what's the right behavior for periodic events in these cases? If >> there is an event that's supposed to run every 5 seconds, and time has >> jumped forward by 16 seconds, it seems reasonable to run the event 1 >> time, or maybe even 3 times... but if time has jumped forward by one >> day, it seems unlikely that the programmer really wants us to run the >> event 17280 times. >> >> Perhaps this argues for a cap on how far into the past we should be >> willing to reschedule a periodic event, or how many "missed firings" >> we'll compensate for before we drop some on the floor? > > > Forward jumps should simply skip events in the past. It is just like events > skipped because the event loop was blocked. > > If you should run every 5 seconds, but woke up 21 seconds late, you cannot > fix the past - you just missed the events at +5, +10, +15 and +20. Run the > next event at +25 according to the plan. > > Other event loops like Cocoa NSRunloop and GNUStep NSRunloop use this logic.
I've implemented approximately this logic in branch "20_periodic_event_overload" in my github repository. (That's where I do most of my work before merging it onto an official branch; it lives at https://github.com/nmathewson/libevent .) I've also got a basic GetTickCount()-based monotonic timer callback for windows merged into the master branch. I'm going to be extending it a little for accuracy, based on some clever hacks from Bittorrent's libutp. -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
