| ▲ | Is it safe to call print in a Python signal handler?(iafisher.com) |
| 61 points by hellerve 5 days ago | 36 comments |
| |
|
| ▲ | nine_k a day ago | parent | next [-] |
| POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler. |
| |
| ▲ | knome a day ago | parent | next [-] | | 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. | | | |
| ▲ | inigyou a day ago | parent | prev | next [-] | | 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. | |
| ▲ | krackers a day ago | parent | prev | next [-] | | >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` https://man7.org/linux/man-pages/man7/signal-safety.7.html | | |
| ▲ | Joker_vD 21 hours ago | parent [-] | | There is also a charming statement in POSIX standard that If the signal occurs other than as the result of calling abort(), raise(),
[CX] [Option Start] kill(), pthread_kill(), or sigqueue(), [Option End] the
behavior is undefined if the signal handler refers to any object with static
storage duration other than by assigning a value to an object declared as
volatile sig_atomic_t, or if the signal handler calls any function in the
standard library other than one of the functions listed in Signal Concepts.
You literally can't read any global/static variables and you can only write to global/static variables that are declared to be volatile sig_atomic_t. This tremendously shrinks the amount of useful work you can do with the signal-safe functions from the standard library. | | |
| ▲ | gpderetta 18 hours ago | parent | next [-] | | C++11/C11 memory model and atomics provide a more well funded model to interact with signal handler. I'm not sure if POSIX fully embraced it, but it will work well in practice. | |
| ▲ | nottorp 21 hours ago | parent | prev [-] | | It may help if you think of them as interrupts and not something that comes in your message queue. | | |
| ▲ | Joker_vD 21 hours ago | parent [-] | | No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. Like, why even bother with supporting function callbacks in sigaction() etc? Just have each thread have a chunk of volatile memory where the kernel writes info about the arrived signals, and that's it, that's your signal handling framework. In fact, here is another, a very fresh, example from POSIX: [0]. There is an example at how to use SIGWINCH signal handler with tcgetwinsize(). Just look at this thing of terrible beauty, notice that SIG_ATOMIC_MAX is not required to bigger than a byte's worth of data, and also read the whole of "APPLICATION USAGE" section. "Multi-threaded applications should avoid the signal handler idiom in general", gee, I wonder why. And of course, the signal may never be generated in the first place, so "[s]uch processes must periodically poll the current terminal window size if needed". What a solid technical foundation to build race-free, bug-free applications on top of. [0] https://pubs.opengroup.org/onlinepubs/9799919799/functions/t... | | |
| ▲ | whateverboat 17 hours ago | parent | next [-] | | > No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. That's how most hardware interrupts would also work. | |
| ▲ | nottorp 20 hours ago | parent | prev | next [-] | | "From boils, mildew and dirt / I've brought forth new beauty and new worth." [1] Let's call them crippled interrupts. As long as you don't think of them as a message queue... In their defense, the original signals were there mostly for "handle this or I'll terminate you" conditions. Then stuff got bolted on... [1] Possibly LLM hallucinated translation from a Romanian poet. Although it did give me a link to a paywalled essay that I couldn't verify. | |
| ▲ | westurner 20 hours ago | parent | prev [-] | | How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should you use signal handlers with eBPF? | | |
| ▲ | kstenerud 18 hours ago | parent [-] | | It's not really possible to make them safer without hurting performance. Signals break the C virtual machine guarantees (atomics, memory consistency, register consistency, etc), and the only way to re-establish them for edge cases like signals would be to cripple the rest of the program with extra checks (basically making ALL data volatile). |
|
|
|
|
| |
| ▲ | pjmlp a day ago | parent | prev [-] | | 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. | | |
| ▲ | germandiago a day ago | parent [-] | | That is exactly what I do: set an stomic variable and do yhings outside of the handler. | | |
| ▲ | masklinn 16 hours ago | parent [-] | | And that is pretty much what Python does for you, the Python-level signal handlers are not C signal handlers. Python sets a C signal handler to set an interpreter variable then exit, then it calls the Python level signal handler on the main thread (and on the main thread only, which can be a concern in sone cases). |
|
|
|
|
| ▲ | IgorPartola a day ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | zbentley a day ago | parent [-] | | What’s the simple way? Self-pipe? | | |
| ▲ | tyffanypastecf 21 hours ago | parent [-] | | Self-pipe, yeah, except in Python you don't have to build it. signal.set_wakeup_fd() is exactly that: hand it an fd (or a socket on Windows) and the interpreter writes the signal number to it. Then you select/poll that fd in your normal loop and do the actual work outside the handler. asyncio uses it under the hood for add_signal_handler. The other one that plays nicely with threads is blocking the signals everywhere with pthread_sigmask and parking one dedicated thread in sigwait(). Both are in the stdlib on Unix. signalfd is nicer than either but it's Linux only, which is why set_wakeup_fd usually wins if you care about portability. |
|
|
|
| ▲ | jrumbut a day ago | parent | prev | next [-] |
| 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. |
|
| ▲ | a day ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | Uptrenda a day ago | parent | prev | next [-] |
| 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 a day ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | inigyou a day ago | parent [-] | | They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt. | | |
| ▲ | shawn_w a day ago | parent | next [-] | | And for people who want to use something other than Linux? | | | |
| ▲ | charcircuit a day ago | parent | prev [-] | | 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. | | |
| ▲ | inigyou 11 hours ago | parent [-] | | Incorrect. With the separate thread approach you added a lot of new race conditions. | | |
| ▲ | charcircuit 4 hours ago | parent [-] | | In practice I don't think there would be that many. You could even pause execution of the thread that would have gotten the signal to make it even safer. |
|
|
|
|
|
| ▲ | fenestella a day ago | parent | prev | next [-] |
| [flagged] |
|
| ▲ | andrewstuart 15 hours ago | parent | prev | next [-] |
| [flagged] |
|
| ▲ | time4tea 20 hours ago | parent | prev | next [-] |
| Betteridge |
|
| ▲ | megagpt3 a day ago | parent | prev [-] |
| He 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. |
| |
| ▲ | lmz a day ago | parent [-] | | 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 | | |
| ▲ | megagpt3 9 hours ago | parent [-] | | But it did crash. Did we read the same article? He shows the output it prints when it crashes. |
|
|
