[issue29971] Lock.acquire() not interruptible on Windows

STINNER Victor added the comment: 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 Date: Wed Sep 22

[issue29971] Lock.acquire() not interruptible on Windows

STINNER Victor added the comment: See also bpo-45301 "pycore_condvar.h: remove Windows conditonal variable emulation". -- ___ Python tracker ___

[issue29971] Lock.acquire() not interruptible on Windows

STINNER Victor added the comment: 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()". -- ___ Python tracker

[issue29971] Lock.acquire() not interruptible on Windows

STINNER Victor added the comment: 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`):

[issue29971] Lock.acquire() not interruptible on Windows

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29971] Lock.acquire() not interruptible on Windows

Change by Eryk Sun : -- components: +Extension Modules, Interpreter Core versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7 ___ Python tracker ___

[issue29971] Lock.acquire() not interruptible on Windows

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg291089 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29971] Lock.acquire() not interruptible on Windows

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue29971] Lock.acquire() not interruptible on Windows

Antoine Pitrou added the comment: 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

[issue29971] Lock.acquire() not interruptible on Windows

Eryk Sun added the comment: 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.

[issue29971] Lock.acquire() not interruptible on Windows

Eryk Sun added the comment: >From the linked issue: > proc.send_signal(CTRL_C_EVENT) raises the KeyboardInterrupt > in both the original and subprocess on Windows GenerateConsoleCtrlEvent takes process group IDs, so it should have been used to implement os.killpg, not os.kill. If you call it

[issue29971] Lock.acquire() not interruptible on Windows

Changes by Josh Rosenberg : -- nosy: +josh.r ___ Python tracker ___ ___

[issue29971] Lock.acquire() not interruptible on Windows

New submission from Antoine Pitrou: 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