POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/
Python or not, almost nothing is safe inside a signal handler.
POSIX 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.
Too funny
And this is explained in more details in the first article of the series.
>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
There is also a charming statement in POSIX standard that
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.It may help if you think of them as interrupts and not something that comes in your message queue.
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...
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?
"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.
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.
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.