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