Timers expire prior to expiry time

Chris Brody chris.brody at gmail.com
Thu Aug 21 22:56:26 CEST 2014

> In cases where the system is under heavy load (a prevalent case in embedded
> systems), this problem can manifest even if the iteration processing time
> prior to setting the timer is in theory short.

This observation is an indication of a potential issue that an
application is not always quickly responsive to external events. The
design of libev favors keeping the processing time per event callback
very short.

I can think of a several ways to achieve this. One would be to rework
the application to less processing per time interval, and to use a
timer to trigger the remaining processing steps in parts until the
processing is finished. Another solution is background processing. Yet
another solution (more difficult) would be to setup multiple processes
listening to the same socket(s).

Consider the response of David Elrom:
> sounds like this could be caused due to a spurious wake up...

This could be. This issue could be avoided by keeping short processing
time per event callback.

> The fix I propose is to have ev_timer_start() call time_update() before
> calculating the expiry timestamp (patch attached).
> I would be glad to know what are your thoughts on this issue, and whether
> this fix is needed and makes sense.

The change would make libev's timer mechanism a bit more robust, which
I do find to be well-justified in an embedded environment.

A workaround would be to call ev_now_update() (which in turn calls the
internal (inline) time_update() function) before calling


More information about the libev mailing list