Eryk Sun <eryk...@gmail.com> added the comment:
> Seems like Windows 7 may need to be considered as well, as > per vstinner's bpo-32592 mention? Python 3.9 doesn't support Windows 7. Moreover, the interpreter DLL in 3.9 implicitly imports PathCchCanonicalizeEx, PathCchCombineEx, and PathCchSkipRoot, which were added in Windows 8. So it won't even load in Windows 7. > Have there been any issues filed about the deadline behaviors > across system suspend? Not that I'm aware of, but waits should be correct and consistent in principle. It shouldn't behave drastically different just because the user closed the laptop lid for an hour. > Looks like Linux (CLOCK_MONOTONIC) and macOS (mach_absolute_time()) > already don't track suspend time in time.monotonic(). I think that's > enough to suggest that long-term Windows shouldn't either I'm not overly concerned here with cross-platform consistency. If Windows hadn't changed the behavior of wait timeouts, then I wouldn't worry about it since most clocks in Windows are biased by the time spent suspended. It's a bonus that this change would also improve cross-platform consistency for time.monotonic(). > I tested QueryUnbiasedInterruptTime() and it exhibits the same > 16ms jitter as GetTickCount64() (which I expected), For bpo-41299, it occurs to me that we've only ever used _PY_EMULATED_WIN_CV, in which case PyCOND_TIMEDWAIT() returns 1 for a timeout, as implemented in _PyCOND_WAIT_MS(). Try changing EnterNonRecursiveMutex() to break out of the loop in this case. For example: } else if (milliseconds != 0) { /* wait at least until the target */ ULONGLONG now, target; QueryUnbiasedInterruptTime(&target); target += milliseconds; while (mutex->locked) { int ret = PyCOND_TIMEDWAIT(&mutex->cv, &mutex->cs, (long long)milliseconds * 1000); if (ret < 0) { result = WAIT_FAILED; break; } if (ret == 1) { /* timeout */ break; } QueryUnbiasedInterruptTime(&now); if (target <= now) break; milliseconds = (DWORD)(target - now); } } ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44328> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com