Why calling print in a Python signal handler can crash your program
Is it safe to call print in a Python signal handler?
Python's signal handling model defers user handlers until the interpreter is safe, but reentrancy can still bite: if a signal arrives mid-print, the handler may call print again, triggering a RuntimeError. This article stress-tests the scenario, explains why it happens, and argues it's a curiosity rather than a practical threat—though it still advises against heavy work in handlers.
Running this program on my machine produced: RuntimeError: reentrant call inside <_io.BufferedWriter name='<stdout>'>
- nine_k
POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/
Python or not, almost nothing is safe inside a signal handler.
- IgorPartola
What’s really fun is mixing signal handling and threads, especially on Linux. There is a simple way to do it and about a thousand ways that include at least one gotcha.
- jrumbut
I think the author undersells the significance of this. I could easily picture someone writing code that boils down to the example, all it requires is a flood of signals and a print statement.
If your program generates signals, it could generate a flood unintentionally. If you put a print statement in the handler, you can get this result.
It's not terribly surprising, but good to know.
- Uptrenda
And when you combine it with event loops and multiple OSes + python versions it gets even more difficult. Don't get me wrong: I love python, but shut down / cleanup is kind of a pain in the ass. If someone built a (good) lib for this it would probably be quite popular.
- charcircuit
I don't understand how this is still a problem in 2026. Signals should just come in via a new thread and it would solve all the complexity around them. Everyone has known the current way it works is extremely limited in what you can safely do. This whole pause the execution of what's currently running and then run some extra code somewhere else turned out to not be a good idea.