Marc Lehmann wrote: >>> * there are two types of timers, based on real time differences and wall >>> clock time (cron-like). timers can also be repeating and be reset at >>> almost no cost (for idle timeouts used by many network servers). time >>> jumps >>> get detected reliably in both directions with or without a monotonic >>> clock. >> But then they're not truly "real-time", no? > > Within the limits of technology, they are: > > - timers (based on monotonic time) will time out after "n" seconds (whatever > was configured), even if the date resets in between (libevent can do that > only for backward time jumps). > > - periodicals will simply be rescheduled, if a periodic timer is scheduled > to fire "at" some point then it will not be affected by the time jump, > it will still fire at that point (its more complicated with periodic > timers scheduled to repeat, if you schedule a periodic timer to execute > on every minute than libev will try to schedule it to occur when time() > % 60 == 0, regardless of any time jumps. > > Of course, detecting and correcting this cnanot be done completely > reliable with sub-second precision (there is no API in posix to do that), > but with a monotonic clock, libev should manage quite fine to detect even > very small time jumps caused by ntpd. > > (With no monotonic clock its a heuristic, obviously).
Have you seen the new Linux timerfd API? Where available, you can wait for CLOCK_MONOTONIC and CLOCK_REALTIME events independently. Beats heuristics, and detecting time jumps sound like introducing a lot of extra timeouts. I'd hate to see libev(ent)? show up on PowerTOP after just getting rid of the 5-second timeout. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
