Hacker News

>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

    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.

nottorp an hour ago [ - ]

It may help if you think of them as interrupts and not something that comes in your message queue.

Joker_vD an hour ago [ - ]

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...

westurner 2 minutes ago [ - ]

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?

nottorp 21 minutes ago [ - ]

"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.