[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 the

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: > It shouldn't behave drastically different just because the user closed the > laptop lid for an hour I talked to someone who's been helping with the Go time APIs and it seems like that holds pretty well for interactive timeouts, but ma

[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 pa

[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

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: > The monotonic clock should thus be based on QueryUnbiasedInterruptTime My primary complaint here is that Windows is the only major platform with a low resolution monotonic clock. Using QueryUnbiasedInterruptTime() on older OS versions wouldn't entir

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: I think a lot of that is based on very outdated information. It's worth reading this article: https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps I will repeat Microsoft's current recommendation (from th

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: Great information, thanks! > Windows 10 also provides QueryInterruptTimePrecise(), which is a hybrid > solution. It uses the performance counter to interpolate a timestamp between > interrupts. I'd prefer to use this for time.monotonic() inst

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: I found these two references: - https://stackoverflow.com/questions/35601880/windows-timing-drift-of-performancecounter-c - https://bugs.python.org/issue10278#msg143209 Which suggest QueryPerformanceCounter() may be bad because it can drift. However, these

[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: https://stackoverflow.

[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 <https://bugs.python.org/issu

[issue44328] time.monotonic() should use QueryPerformanceCounter() on Windows

New submission from Ryan Hileman : Related to https://bugs.python.org/issue41299#msg395220 Presumably `time.monotonic()` on Windows historically used GetTickCount64() because QueryPerformanceCounter() could fail. However, that hasn't been the case since Windows XP:

[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 <https://bugs.python.org/issue41299> ___ ___ Python-bugs-list m

[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

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: > Sounds good to me. We can deprecate RESTRICTED with no intention to remove it, since it's documented. > Do you want to prepare a PR for this? In case you missed it, the attached PR 24182 as of commit d3e998b is based on the steps I listed - I m

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: Just updated the PR with another much simpler attempt, using a new READ_AUDIT flag (aliased to READ_RESTRICTED, and newtypes documentation updated). I re-ran timings for the new build, and in all cases they match or slightly beat my previous reported timings

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: I agree that READ_RESTRICTED would work, and I'm strongly in support of refactoring my patch around that kind of flag, as it simplifies it quite a bit and the if statement is already there. However, using the seemingly legacy RESTRICTED flag names for

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: How's this for maintainable? https://github.com/lunixbochs/cpython/commit/2bf1cc93d19a49cbed09b45f7dbb00212229f0a1 -- ___ Python tracker <https://bugs.python.org/is

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: My understanding as per the outline in PEP 551 as well as PEP 578, is that the audit system is meant primarily to observe the behavior of code rather than to have good sandbox coverage / directly prevent behavior. I am using audit hooks to observe the

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: My personal motivation is not to unilaterally prevent access to globals, but to close a simpler gap in the audit system that affects a currently deployed high performance production system (which is not trying to be a sandbox). I am also already using a C

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: I just found out that generator object variants have their own code attributes. I investigated the stdlib usage and it seems to be for debug / dis only, so adding these attributes shouldn't impact performance. I updated the PR to now cover the foll

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: PR submitted, waiting on CLA process. I added documentation at the field sites, but the audit event table generation does not handle attributes or object.__getattr__ very well at all, so I'm not updating the audit table for now. The `.. audit-event:: o

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Change by Ryan Hileman : -- keywords: +patch pull_requests: +23010 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24182 ___ Python tracker <https://bugs.python.org/issu

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: Oops, by tb_code I meant traceback.tb_frame.f_code. So you can get to a frame from traceback.tb_frame (without triggering audit) or sys._getframe (which has an audit hook already), and you can get to __code__ from a frame via frame.f_code (without triggering

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: I'm definitely not proposing to hook all of object.__getattr__, as my intuition says that would be very slow. I simply refer to "object.__getattr__" as the event name used by a couple of rare event audit hooks. This is how getting __code__ is

[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

Ryan Hileman added the comment: traceback's `tb_code` attribute also allows you to bypass the `object.__getattr__` audit event for `__code__`. Perhaps accessing a traceback object's `tb_code` and `tb_frame` should both raise an `object.__getattr__` event? -- nosy: +l