[Libevent-users] announcing libev, towards a faster and more
featureful libevent
Scott Lamb
slamb at slamb.org
Sun Nov 4 19:09:08 EST 2007
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.
More information about the Libevent-users
mailing list