Please run joinbug.py and press Ctrl-C twice.

============= The output  =============

1st join
PLEASE PRESS CTRL-C TWICE, IGNORE THE 'Press any key to continue'
Press any key to continue . . . Press any key to continue . . .

thread exit
Traceback (most recent call last):
  File "D:\xxx\joinbug.py", line 21, in <module>
    t.join() # subprocess.Popen() makes join() can be interrupted
  File "C:\Users\xxx\AppData\Local\Programs\Python\Python39\lib\threading.py", line 1033, in join
    self._wait_for_tstate_lock()
  File "C:\Users\xxx\AppData\Local\Programs\Python\Python39\lib\threading.py", line 1049, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
2nd join
(stuck here)


============= Expected behaviour =============
either join uninterruptible
or the 2nd join doesn't deadlock.

This is a variation on bpo-21822. If join() is called in the main thread, and it gets interrupted immediately after the lock.acquire(block, timeout) call, then subsequent calls will hang. In Windows, the acquire() call is not interruptible with Ctrl+C, so the KeyboardInterrupt gets raised immediately after acquire() returns, so the problem is easy to reproduce in Windows.