On Fri, Oct 14, 2011 at 12:48 AM, Shaun Lindsay <[email protected]> wrote: > The problem isn't the volume of timer events. Condensing all the timeouts > to one actual event won't help since, as shown in the example, a single > timeout is vulnerable to early expiration. Basing all your timeouts off of > that would just cause everything to expire early (Although using one event > and a backing list seems like a really cool way of squeezing a huge number > of events in to the system).
Setting the timeout lower priority than the i/o (I believe Marc already mentioned this) would help too. However, having an error timeout window that's even roughly in the ballpark of the time it takes to process one set of pending i/o callbacks, I'm not sure you can avoid taking at least a single ev_time() hit when setting each timeout watcher (or in the Strategy 4 optimization, an ev_time() hit as you add/update each linked list entry). Without it there's no way to account for the lost time, and with the loop iteration duration and the timeout being of the same rough magnitude, it matters. There's no magic bullet for that problem, something has to give, and ev_time() hits are cheaper than ev_update_now() hits. "Normal" libev software doesn't see these problems in practice because a typical event loop iteration completes in a very small fraction of the timeout window (e.g. 50ms to process pending events vs a 60 second inactivity timeout). -- Brandon _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
