You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revert "[runloop] Ensure timing arithmetic is done in ns."
This shouldn't bite OpenBSD 7.1 and may fix regressions on Windows. The
underlying time code is still a little suspect, but this might be the
safest thing to do right now.
// On Windows, we have observed an issue where the timer port is set before the time which we requested it to be set. For example, we set the fire time to be TSR 167646765860, but it is actually observed firing at TSR 167646764145, which is 1715 ticks early. The result is that, when __CFRunLoopDoTimers checks to see if any of the run loop timers should be firing, it appears to be 'too early' for the next timer, and no timers are handled.
3198
3189
// In this case, the timer port has been automatically reset (since it was returned from MsgWaitForMultipleObjectsEx), and if we do not re-arm it, then no timers will ever be serviced again unless something adjusts the timer list (e.g. adding or removing timers). The fix for the issue is to reset the timer here if CFRunLoopDoTimers did not handle a timer itself. 9308754
3199
-
if (!__CFRunLoopDoTimers(rl, rlm, __CFNanosecondsToTSR(mach_absolute_time()))) {
3190
+
if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
3200
3191
// Re-arm the next timer
3201
3192
// Since we'll be resetting the same timer as before
3202
3193
// with the same deadlines, we need to reset these
0 commit comments