> 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 ev_timer_start(). Chris _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
