I'm no expert on libev, but sounds like this could be caused due to a spurious wake up...
On Thu, Aug 21, 2014 at 9:33 AM, Aviv Heller (avheller) <avhel...@cisco.com> wrote: > Hi, > > I have encountered a problem, on version 4.11 of the library, where a > timer started expired prior to its intended expiry time. > > This happened because time_update() is not called by ev_timer_start() > prior to calculating the expiry timestamp, which in cases where a timer is > started after a long processing time during a loop iteration, results in > ev_timer_start() using an old time instead of the current one. > > 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. > > 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. > > Thanks, > Aviv > > _______________________________________________ > libev mailing list > libev@lists.schmorp.de > http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev >
_______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
