MCVE:
import threading
threading.Thread(target=input, daemon=True).start()
If you run the above as a script in PyCharm with the default run configuration (without entering any input), you get the following fatal error when the program terminates:
Fatal Python error: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=00000200EF89E1C0)
Thread 0x0000459c (most recent call first):
File "C:\Program Files\Python38\lib\threading.py", line 870 in run
File "C:\Program Files\Python38\lib\threading.py", line 932 in _bootstrap_inner
File "C:\Program Files\Python38\lib\threading.py", line 890 in _bootstrap
Current thread 0x00001b78 (most recent call first):
<no Python frame>
But if you run this from the terminal with python script.py or check the "Emulate terminal in output console" in PyCharm for this run configuration, no such error occurs.
As far as I understand, the error happens because when input is called, it suspends the thread indeterminately until input returns (and there's no way of interrupting this), blocking stdin during this time, so when the main thread terminates, since the other thread is a daemon, Python starts finalization, and when it tries to reacquire the lock for stdin, it can't because it is still locked by the input call.
But the question is, why does it make a difference whether it is run in PyCharm's output console vs a terminal/terminal emulator? Does the terminal make Python not try to reacquire the lock? Or does the error still occur but it gets silenced for some reason? Or what?
If case this helps, in CPython, this error is raised in the _enter_buffered_busy function in bufferedio.c.
UPDATE: I've filed a ticket on PyCharm's issue tracker.