[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I close the issue. > bpo-41299: Fix EnterNonRecursiveMutex() (GH-28548) I don't think that it's worth it to backport this change to 3.9 and 3.10. In practice, Py_FatalError() will never be called, and _PyTime_GetMonotonicClock() result must always be

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: New changeset 6bc89116cb121c176453b9745e3daa2cc5df43ab by Victor Stinner in branch 'main': bpo-41299: Mark private thread_nt.h functions as static (GH-28553) https://github.com/python/cpython/commit/6bc89116cb121c176453b9745e3daa2cc5df43ab --

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: New changeset d639e3170506a1a80c4b2f1b3a6250bb95ff190a by Victor Stinner in branch 'main': bpo-41299: Fix EnterNonRecursiveMutex() (GH-28548) https://github.com/python/cpython/commit/d639e3170506a1a80c4b2f1b3a6250bb95ff190a --

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: New changeset f35ddf24227e834c9b6b39ad23a0ec382b4de48b by Victor Stinner in branch 'main': bpo-41299: QueryPerformanceFrequency() cannot fail (GH-28552) https://github.com/python/cpython/commit/f35ddf24227e834c9b6b39ad23a0ec382b4de48b --

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by STINNER Victor : -- pull_requests: +26936 pull_request: https://github.com/python/cpython/pull/28553 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by STINNER Victor : -- pull_requests: +26935 pull_request: https://github.com/python/cpython/pull/28552 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: Calling Py_FatalError() must be avoided by any mean. I spent significant time to remove Py_FatalError() at Python startup in my PEP 587 implementation: https://www.python.org/dev/peps/pep-0587/ I also removed Py_FatalError() calls to report errors to the

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I created PR #28548 to remove the Py_FatalError() code path. -- ___ Python tracker ___ ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by STINNER Victor : -- pull_requests: +26931 pull_request: https://github.com/python/cpython/pull/28548 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Pablo Galindo Salgado added the comment: New changeset 8673b77e251e42874501a47b1df86c6bde4fe1d2 by Miss Islington (bot) in branch '3.10': bpo-41299: Reduce lag in Windows threading timeouts by using a higher precision time source (GH-26568) (GH-26580)

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: > My read is that as long as we're not confident enough to remove those checks > from pytime.c, a caller should assume they're reachable. If the pytime checks > need to stay, adding a Windows only pytime init check to make sure that locks > won't deadlock

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: > Do you think that pytime.c has the bug? I don't think so. No, a misaligned stack would be an issue in the caller or compiler, not pytime.c. I have hit misaligned stack in practice, but it should be rare enough to check on init only. > In theory yes, in

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: > I mention the QueryPerformanceFrequency error case here (stack misalignment): > https://bugs.python.org/issue41299#msg395237 Do you think that pytime.c has the bug? I don't think so. > There are three places win_perf_counter_frequency() can fail: >

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I'm fine with adding _PyTime_Init() again, and maybe only implement checks on Windows. On Linux, I only saw a single failure in _PyTime_Init() once, when Python was run in a sandbox, and the time syscalls were not allowed. It was a corner case about the

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: Perhaps the simplest initial fix would be to move that check down to PyThread__init_thread() in the same file. I'm not sure what the cpython convention for that kind of init error is, would it just be the same Py_FatalError block or is there a better pattern?

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: I agree with not throwing fatal errors, but that check is unlikely to actually be hit, and you removed the startup checks covering the underlying clocks here: https://github.com/python/cpython/commit/ae6cd7cfdab0599139002c526953d907696d9eef I think if the

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

STINNER Victor added the comment: I suggest to remove the (now <= 0) check. _PyTime_t now = _PyTime_GetPerfCounter(); if (now <= 0) { Py_FatalError("_PyTime_GetPerfCounter() == 0"); } Please don't add such Py_FatalError() in the middle of a function. If

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

miss-islington added the comment: New changeset 57b3ca7f0aef4d180038d475398f809d3fcdd8be by Miss Islington (bot) in branch '3.9': bpo-41299: Reduce lag in Windows threading timeouts by using a higher precision time source (GH-26568)

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by miss-islington : -- pull_requests: +25168 pull_request: https://github.com/python/cpython/pull/26580 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Steve Dower added the comment: New changeset 449e6f0ef395231e3abe467f910b02d7f075c27f by Ryan Hileman in branch 'main': bpo-41299: Reduce lag in Windows threading timeouts by using a higher precision time source (GH-26568)

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by miss-islington : -- nosy: +miss-islington nosy_count: 10.0 -> 11.0 pull_requests: +25167 pull_request: https://github.com/python/cpython/pull/26579 ___ Python tracker

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Steve Dower added the comment: Change looks good. 3.8 is security fixes only at this stage, but it can go back to 3.9 -- versions: -Python 3.8 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: Ok, I filed a PR for this. I used pytime's interface to avoid duplicating the QueryPerformanceFrequency() code. I found a StackOverflow answer that says QueryPerformance functions will only fail if you pass in an unaligned pointer:

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by Ryan Hileman : -- keywords: +patch pull_requests: +25157 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26568 ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Change by Ryan Hileman : -- versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ryan Hileman added the comment: I just ran into this. GetTickCount64() is a bad choice even without improving the Windows timer resolution, as every mutex wait will have 16ms of jitter. Here are some lock.acquire(timeout=0.001) times measured with time.perf_counter(): elapsed=21.215ms

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

SD added the comment: So there is no advised way around this then. I am currently using time.sleep() to hit my 60hz. -- ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Eryk Sun added the comment: > or 500 us with the undocumented NtSetSystemTime system call Umm... that should be NtSetTimerResolution. ;-) -- ___ Python tracker ___

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Eryk Sun added the comment: > On the smaller scale, it looks quantized to multiples of ~15ms (?), > but then it gets more accurate as the times get larger. I don't > think it's a measurement error since the first measurement manages > microseconds. NT's default system timer resolution for

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Steve Dower added the comment: At a guess, it's probably the signal emulation (a.k.a. Ctrl+C support). We could save some time by checking the requested handle first without blocking, and only beginning the blocking call if it's not available. --

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ned Deily added the comment: Thanks for the version info. Windows and/or threading experts: any ideas? -- components: +Library (Lib), Windows nosy: +paul.moore, pitrou, steve.dower, tim.golden, zach.ware ___ Python tracker

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

SD added the comment: I have tested this both on vs code terminal and cygwin for windows. 3.8.2 : python -m test.pythoninfo Python debug information Py_DEBUG: No (sys.gettotalrefcount() missing) _decimal.__libmpdec_version__: 2.4.2 builtins.float.double_format:

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Dennis Sweeney added the comment: I reproduced something similar on Python 3.9.0b1, Windows 64-bit version: py -m pyperf timeit -s "import threading; E = threading.Event()" "E.wait()" NUMBERMean +- std dev --- 0.0 5.79 us

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

Ned Deily added the comment: Please provide the results of running the following with the two pythons you are using: python -m test.pythoninfo For what it's worth, running on macOS 10.15.5, I see a slight difference with more variability in the Python 3 results but nothing as pronounced as

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

New submission from SD : The overhead in Python 3 for threading.Event().wait() is much larger than Python 2. I am trying to run a script at 60hz which worked correctly in Python2 but does not in Python 3. Here is a minimal example to demonstrate: #!/usr/bin/env python import threading