classification
Title: threading.Lock.acquire() not interruptible on Windows
Type: enhancement Stage:
Components: Extension Modules, Interpreter Core, Library (Lib), Windows Versions: Python 3.10, Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, josh.r, kristjan.jonsson, paul.moore, pitrou, steve.dower, tim.golden, tim.peters, vstinner, zach.ware
Priority: normal Keywords:

Created on 2017-04-03 14:43 by pitrou, last changed 2021-09-27 22:04 by serhiy.storchaka.

Messages (7)
msg291072 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-04-03 14:43
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 https://github.com/dask/dask/pull/2144#issuecomment-290556996 for original report.
msg291094 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-04-03 22:11
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, issue 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.
msg291113 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-04-04 08:27
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.
msg402715 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-27 14:07
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-L146
msg402719 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-27 14:12
See also bpo-21822: some comments are about this issue. It's a duplicate of bpo-45274 "Race condition in Thread._wait_for_tstate_lock()".
msg402722 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-27 14:26
See also bpo-45301 "pycore_condvar.h: remove Windows conditonal variable emulation".
msg402731 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-27 16:09
time.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 58f8adfda3c2b42f654a55500e8e3a6433cb95f2
Author: Victor Stinner <vstinner@python.org>
Date:   Wed Sep 22 16:09:30 2021 +0200

    bpo-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>
History
Date User Action Args
2021-09-27 22:04:27serhiy.storchakasettitle: Lock.acquire() not interruptible on Windows -> threading.Lock.acquire() not interruptible on Windows
2021-09-27 16:09:07vstinnersetmessages: + msg402731
2021-09-27 14:26:34vstinnersetmessages: + msg402722
2021-09-27 14:12:51vstinnersetmessages: + msg402719
2021-09-27 14:07:51vstinnersetnosy: + vstinner
messages: + msg402715
2021-03-20 14:33:22vstinnersetnosy: - vstinner
2021-03-20 07:02:35eryksunsetcomponents: + Extension Modules, Interpreter Core
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.7
2021-03-20 07:01:28eryksunsetmessages: - msg291089
2017-04-04 09:12:10vstinnersetnosy: + vstinner
2017-04-04 08:27:28pitrousetnosy: + tim.peters
messages: + msg291113
2017-04-03 22:11:52eryksunsetmessages: + msg291094
2017-04-03 18:19:01eryksunsetnosy: + eryksun
messages: + msg291089
2017-04-03 17:03:54josh.rsetnosy: + josh.r
2017-04-03 14:43:38pitroucreate