On Thursday, 22 June 2017 10:19:52 UTC-4, Daryl Haresign wrote: > > On Thursday, 22 June 2017 08:58:33 UTC-4, Saúl Ibarra Corretgé wrote: >> >> and blocking in a check callback would also make timers run late, which >> cannot be addressed, so personally, I don’t see myself supporting this >> change. >> > > Blocking in a check callback would not make timers which are not due to > run yet, run late. Before the timers are run, the time is updated at the > start of the loop (or in the special RUN_ONCE case). > > This phenomenon only occurs because the poll timeout calculation uses the > stale version of 'now', and thus thinks it can poll for longer than it > should. >
Actually I see what you are saying. The poll timeout would be calculated correctly such that once polling timed out, a timer would be due (if there are any timers, and if polling did indeed timeout). In this case, any check or close callback would be taking up time whilst there are timers waiting to be called. This is you say cannot be addressed. But I think improving the reliability of timers in all the other conditions is a net positive. Thanks, Daryl. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
