| ▲ | nine_k a day ago |
| 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 a day 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 20 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 a day ago | parent | prev [-] | | It may help if you think of them as interrupts and not something that comes in your message queue. | | |
| ▲ | Joker_vD a day 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 18 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 a day 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 21 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 20 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 18 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). |
|
|
