[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

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

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

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

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Géry added the comment: I am having the same blocked signal issue on Windows when using Thread.join. This program does not print "interrupted" after pressing Ctrl+C: import threading import time def f(): while True: print("processing") time.sleep(1) if __name__ ==

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Change by Steve : -- nosy: -tupl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

gaborbernat added the comment: I think I'm hitting this with subprocesses inside tox (parallel feature), any plans to fix this? -- nosy: +gaborbernat ___ Python tracker ___

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Good point, I forgot about WaitForMultipleObjectsEx; something like that seems like it would be much simpler for the first 2 cases. -- ___ Python tracker

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

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

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Okay, I think I need to abandon my research into this. This does seem to have quite an amount of complexity to it and is probably more than I should be taking on at this point in time. Anyone else who wants to look at this, consider it

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Ahh, thanks for the explanation. I didn't think about that. Let's *not* do that then. :) I'll see if I can squeeze in some time to play with the alternatives. -- ___ Python tracker

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou added the comment: > I'm guessing this is because of the perceived performance impact? The problem is polling is pretty detrimental to power saving on modern CPUs. There might also be a performance impact that makes things worse :-) More generally, we really

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: > I think adding polling to such a widely-used primitive is out of question. I'm guessing this is because of the perceived performance impact? (That's the main thought I have against polling in this case.) Or is it something else? I can

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou added the comment: > One way to possibly make this work (although perhaps not as clean as may be > desired) would be to add polling logic into the thread_nt.h version of > PyThread_acquire_lock_timed. I think adding polling to such a widely-used primitive is

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Focusing on the Windows case specifically... One way to possibly make this work (although perhaps not as clean as may be desired) would be to add polling logic into the thread_nt.h version of PyThread_acquire_lock_timed. That would have

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Eryk Sun added the comment: For POSIX systems, try the following test function several times. For the bug to manifest, Thread._wait_for_tstate_lock has to be interrupted in between acquiring and releasing the sentinel lock. Maybe it could use a reentrant lock in order to

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Not sure if I'll do the full fix (need to check w/ my employer), but I'm doing some investigation. Here's what I know so far: At the Python level, the KeyboardInterrupt is being raised within _wait_for_tstate_lock, on "elif

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou added the comment: Thanks for the update. Since I still can't reproduce on Linux, perhaps you (or one of our resident Windows experts) can try to propose a patch fixing the issue? -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden,

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: I've confirmed this issue on Windows. Attached is an SSCCE which seems to reliably reproduce the issue in a Windows environment. Long story short: if a KeyboardInterrupt occurs during Thread.join(), there's a good chance that

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21822 ___ ___ Python-bugs-list

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +neologix, pitrou, tim.peters type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21822 ___

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou added the comment: This works for me under Linux. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21822 ___ ___ Python-bugs-list

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

New submission from Steve: I am attempting to join a thread after a previous join was interrupted by Ctrl-C. I did not find any warning for this case in threading module docs, so I assume this is legal. The full test script is attached, but the essential code is: def work(t): sleep(t)