On Sat, Oct 15, 2011 at 1:40 AM, Denis Bilenko <[email protected]> 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 _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
