alternate approach to timer inaccuracy due to cached times

[Brandon Black]

On Sat, Oct 15, 2011 at 1:40 AM, Denis Bilenko <denis.bilenko at gmail.com> wrote:
> Giving the IO watcher higher priority than ev_timer's would not work
> here, would it?
> IIRC, priorities only matter within the same loop iteration, here the
> issue occurs when
> the timer has got an event but the IO hasn't yet.

Priorities should still fix things, within the limitation that they
can't make the timer fire "on time" if the loop iteration is taking
longer than the timeout value.  The loop runs in two distinct phases:
event gathering followed by callback execution.  Even if your callback
execution time is 1000ms, and at the end of the last callback you set
an i/o timeout for 500ms, if another i/o arrived during the 1000ms you
were blocking the loop, and the i/o watcher has higher priority than
the timeout watcher, the i/o callback will be invoked before the
timeout callback on the next iteration (at which point it can reset it
for another 500ms, rather than letting it invoke immediately).  If you
set the timeout priority lower than the i/o priority and it still
invokes immediately on the next loop iteration, in practice that means
you really did have no incoming i/o for a period of longer than 500ms.

-- Brandon