Eryk Sun <[email protected]> added the comment:
Changing the system timer resolution doesn't appear to help, given the current
design combined with what looks like a bug in Windows (at least in Windows 10).
We can set the system clock resolution below a millisecond via
NtSetTimerResolution. I tested at 0.4882 ms, which allowed sleeping for 0.5 ms
via NtDelayExectution. (NT interval resolution is 100 ns, nominally). But
Python's threading Lock timeout is still limited to about 15-16 ms. I'd expect
1 ms resolution given we're ultimately calling WaitForSingleObjectEx via
PyCOND_TIMEDWAIT -> _PyCOND_WAIT_MS.
It appears the problem is that GetTickCount[64] continues to increment by
15.625 ms (i.e. by 15 to 16), which looks like a bug to me, but may be a
compatibility behavior. We use the tick count in EnterNonRecursiveMutex in the
following block of code:
} else if (milliseconds != 0) {
/* wait at least until the target */
DWORD now, target = GetTickCount() + milliseconds;
while (mutex->locked) {
if (PyCOND_TIMEDWAIT(&mutex->cv, &mutex->cs, (long
long)milliseconds*1000) < 0) {
result = WAIT_FAILED;
break;
}
now = GetTickCount();
if (target <= now)
break;
milliseconds = target-now;
}
}
----------
nosy: +eryksun
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34535>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
