[flagged]
Is it safe to call print in a Python signal handler?
11–20 of 39 posts
Re: Is it safe to call print in a Python signal handler?
#12POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.
Certain signals are true user-mode interrupts, like SIGTERM and some of the ones glibc uses to implement pthreads.
The ones related to application logic must only be handled with signalfd if you want any semblance of reliability.
Re: Is it safe to call print in a Python signal handler?
#13I 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.
They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt.
Re: Is it safe to call print in a Python signal handler?
#14He considers it safe if it's unlikely to crash? That's also true in C. Calling printf in a C signal handler is likely to work. So why does he consider it important in C but "not a practical consideration" in Python? It's more likely to crash in Python than in C because the signal handler takes longer to execute.
The article mentions that the Python handler is run outside of the C handler context and so is not subject to the C safety restrictions. It will not crash since the interpreter only calls the Python handler when it is safe. It will however not protect against reentrancy issues in the Python handler.
The C printf function is not async signal safe and is one of the examples in the manual: https://man7.org/linux/man-pages/man7/signal-safety.7.html
Re: Is it safe to call print in a Python signal handler?
#15I 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.
They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt.
That is also good, but requires apps be rewritten to read from signalfd. With the separate thread approach you can get away without having to rewrite programs.
Re: Is it safe to call print in a Python signal handler?
#16I 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.
They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt.
And for people who want to use something other than Linux?
Re: Is it safe to call print in a Python signal handler?
#17POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.
Exactly, the only safe thing to do in a signal is set a variable for other code to react on, also they completely mess up in multi-threaded code.
Re: Is it safe to call print in a Python signal handler?
#18POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.
the first line of the article points out that python isn't run in the POSIX C handler. that just sets a flag for the interpreter to act on. the python issue is an unsafe re-entrant handling strategy in the interpreter.
And this is explained in more details in the first article of the series.
Re: Is it safe to call print in a Python signal handler?
#19POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.
>almost nothing is safe
That's a bit of an overstatement? There's a list of things that you _can_ call, and fairly useful ones too like `write`
Re: Is it safe to call print in a Python signal handler?
#20POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.
Exactly, the only safe thing to do in a signal is set a variable for other code to react on, also they completely mess up in multi-threaded code.
That is exactly what I do: set an stomic variable and do yhings outside of the handler.