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
