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.

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.

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-L146

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()".

See also bpo-45301 "pycore_condvar.h: remove Windows conditonal variable emulation".

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>