Eryk Sun <eryk...@gmail.com> 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 avoid this problem.
import os
import signal
import threading
import time
def raise_sigint():
print('raising SIGINT')
time.sleep(0.5)
if os.name == 'nt':
os.kill(0, signal.CTRL_C_EVENT)
else:
os.kill(os.getpid(), signal.SIGINT)
print('finishing')
def test(f=raise_sigint):
global g_sigint
g_sigint = threading.Thread(target=f, name='SIGINT')
g_sigint.start()
print('waiting')
for i in range(100):
try:
if not g_sigint.is_alive():
break
g_sigint.join(0.01)
except KeyboardInterrupt:
print('KeyboardInterrupt ignored')
print('g_sigint is alive:', g_sigint.is_alive())
POSIX-only code normally wouldn't join() with a small timeout in a loop as in
the above example. This is a workaround for the problem that's demonstrated in
msg221180, in which a signal doesn't interrupt a wait on the main thread. Other
than time.sleep(), most waits in Windows CPython have not been updated to
include the SIGINT Event object when waiting in the main thread. (It's possible
to fix some cases such as waiting on locks, but only as long as the
implementation continues to use semaphores and kernel waits instead of native
condition variables with SRW locks.)
----------
nosy: +eryksun
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21822>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
