The code attached runs a while loop that prints, and has a signal handler that also prints. There is a thread that constantly fires off signals, but this is just to ensure the condition for the bug happens -- this is a bug with signal handling, not threads -- I can trigger a RuntimeError (... with a missing message?) by commenting out the threading lines and instead running a separate process "while true; do kill -s SIGUSR1 4687; done".

Traceback:

$ python3 threading_print_test.py 
hello
world
Traceback (most recent call last):
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 36, in <module>
    main()
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 30, in main
    print("world")
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 13, in print_hello
    print("hello")
RuntimeError: reentrant call inside <_io.BufferedWriter name='<stdout>'>

> RuntimeError: reentrant call inside <_io.BufferedWriter name='<stdout>'>

As the exception message suggests: the IO stack is not reentrant. If an ongoing IO call is interrupted by a signal, and the signal handler calls again into the IO stack, this situation is detected and an error is raised. If instead we allowed the IO call to continue, all sorts of problems could ensue (data loss, crashes...).

So, indeed, print() is not safe in signal handlers. Though the fact that it raises an exception, rather than crashes, makes things easier for the developer ;)

It doesn't do any of those things in Python 2, to my knowledge. Why aren't we willing to make this work?

> It doesn't do any of those things in Python 2, to my knowledge.

Well, even if Python 2 doesn't warn you,  threading_print_test.py is also wrong on Python 2. Python 3 is better because it warns you :-)

> Why aren't we willing to make this work?

It would be very complex to support reentrant calls in the io stack. It's much easier to redesign your application to defer the work of the signal handler outside the signal handler.