alternate approach to timer inaccuracy due to cached times

[Brandon Black]

On Fri, Oct 14, 2011 at 12:48 AM, Shaun Lindsay <srlindsay at gmail.com> 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