Thanks for your reply. On Thursday, 22 June 2017 08:58:33 UTC-4, Saúl Ibarra Corretgé wrote: > > That would mean that we update the loop time at least twice per loop > iteration, which is what we wanted to avoid in the first place. > The temporary solution I have gone with uses a prepare handle to update the time. This does mean that the time is updated twice per loop iteration, which I agree is not ideal based on the premise that libuv should avoid making too many time related system calls.
This is why I like my proposed change: you would not update the time *at least* twice per loop iteration. You would update the time *at most* twice per loop iteration (at least implicitly, obviously the user of libuv can make it happen more). Updating the time would be done within uv__next_timeout, so it would only happen if uv_backend_timeout didn't already exit early due to one of the many conditions which leads to a poll timeout of zero. This would only be the case if you have no idle handles, no pending queue items, and no handles pending close. (I'll admit that I also thought this included no active handles or requests, but reading it again I see it's the opposite.) Note that timers will run late if you decide to block on *any* callback > really. The programming model based on an event loop has this inherent > limitation, and your suggestion would just be a bandaid for a single use > case, which is timers. Yes, they would. And this change would work no matter which type of callback is blocked. The change would merely ensure that the poll timeout doesn't exceed when a timer is due, leading to the timer skewing. > libuv caters to a larger audience than Node, I am actually attempting to integrate libuv into my application, not use node. I gave example node code because a) I was surprised it was an issue there, and b) like my use case, node doesn't really have a way to determine whether the timers will be skewed. Note that a quick search on Google will yield a bunch of people implementing setInterval in script because of this exact issue. They implement it in terms of setTimeout, calculating the new timeout on every callback based on the difference between when the callback finished running and when the next callback should be executed. This necessarily involves way more time related system calls. > 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. It would be the case that timers are still running late even with this change, if the amount of work performed in a loop iteration exceeded the timer interval, but there is nothing that can be done to solve that. 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.
