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

Reply via email to