Repository navigation
threading.Lock.acquire() not interruptible on Windows #74157
Description
Activity
On Windows, Lock.acquire() (and other synchronization primitives derived from it, such as queue.Queue) cannot be interrupted with Ctrl-C, which makes it difficult to interrupt a process waiting on such a primitive.
Judging by the code in Python/_thread_nt.h, it should be relatively easy to add such support for the "legacy" semaphore-based implementation (by using WaitForMultipleObjects instead of WaitForSingleObject), but it would be much hairier for the new condition variable-based implementation.
Of course, many other library calls are prone to this limitation (not being interruptible with Ctrl-C on Windows).
See dask/dask#2144 (comment) for original report.
Alternatively we could use the SleepEx and WaitFor*Ex functions with alertable waits (i.e. using APCs) instead of the SIGINT Event. This avoids having to replace all single-object waits with multiple-object waits, and would even allow calling SleepEx in pysleep.
That said, bpo-29871 proposes to switch to the condition variable and SRW lock implementation, so first it needs to be decided whether to continue to use kernel waits or switch to conditional variables. Or maybe refactor to use condition variables in performance-critical code and otherwise use kernel waits, if that makes sense.
An orthogonal improvement is to have the signal handler call CancelSynchronousIo. This would entail handling ERROR_OPERATION_ABORTED in _winapi Readfile, WriteFile, and WaitNamedPipe by calling PyErr_CheckSignals. Also in _Py_Read and _Py_Write, if errno is EINVAL and the last Windows error is ERROR_OPERATION_ABORTED, it could manually set errno to EINTR.
Winsock waits (e.g. select) will remain a problem in any case. Winsock uses alertable waits, so a queued user-mode APC will be executed while it's waiting. But then it just resumes its original wait instead of failing with WSAEINTR.
I am not competent enough to pronounce on the technical detail of what you are proposing, but:
Or maybe refactor to use condition variables in performance-critical code and otherwise use kernel waits, if that makes sense.
That can make sense IMHO. Lock and RLock are Python-facing objects, so I'm not sure using high-performance userspace primitives is really important there (after all, people will primarily suffer the evaluation cost of pure Python code so, unless you do something silly such as acquire and release a Python lock in a loop, the acquisition cost doesn't really matter). OTOH, the GIL may be more performance-critical (and needn't be interrupted), so can use userspace CV primitives.
That will however entail a complication of the internal locking API, since we basically need two separate PyThread lock APIs: an "interruptible lock" API and a "fast lock" API.
Copy of Antoine Pitrou's msg316024 (bpo-21822):
multiprocessing semaphores support Ctrl-C under Windows, so it should be doable for regular locks as well (notice the
sigint_event):
https://github.com/python/cpython/blob/master/Modules/_multiprocessing/semaphore.c#L109-L146time.sleep() is now implemented with a waitable timer and WaitForMultipleObjects() on Windows. It uses _PyOS_SigintEvent() so it can be interrupted with CTRL+C.
commit 58f8adf
Author: Victor Stinner <vstinner@python.org>
Date: Wed Sep 22 16:09:30 2021 +0200bpo-21302: time.sleep() uses waitable timer on Windows (GH-28483) On Windows, time.sleep() now uses a waitable timer which has a resolution of 100 ns (10^-7 sec). Previously, it had a solution of 1 ms (10^-3 sec). * On Windows, time.sleep() now calls PyErr_CheckSignals() before resetting the SIGINT event. * Add _PyTime_As100Nanoseconds() function. * Complete and update time.sleep() documentation. Co-authored-by: Livius <egyszeregy@freemail.hu>- changed the title
[-]Lock.acquire() not interruptible on Windows[/-][+]threading.Lock.acquire() not interruptible on Windows[/+]on Sep 27, 2021 This is fixed by #134747 which made locks interruptible on Windows.
Reacted by Victor Stinner
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: