Linux Signals – Internals

[nemaar]

I really hope when the time comes and someone reinvents the wheel and comes up with a new great OS, the new OS will NOT have signals. Those are one of the worst things ever invented. The idea that your code is randomly interrupted and it starts to execute something else is just mind-blowingly bad. The real fun comes when you want to use different libraries with different signal handling ideas in the same process. It all goes to very quickly. The worst thing is that no one had the courage to say "okay guys, this is bad, let's just forget it ever existed and create a better alternative". /rant

[smcl]

I'm not an operating systems person, so I'm curious - what are the alternatives?

[rwl4]

Signals are almost the app version of interrupts which is a fundamental way the peripherals (and your programs!) communicate with the kernel.

Sure handling them can be a pain in the ass, but I'd argue that signals are beautiful in their simplicity and extremely powerful. They are used for far more than signaling hang up and termination.

[zAy0LfpBZLC8mAC]

It should be noted that the example code is defective: printf() is being called inside the while loop and in the signal handler, which could lead to the printf() in the loop being interrupted by the signal handler, which would call printf() again, but printf() is not reentrant.

[FreeFull]

Doesn't ctrl-z actually send SIGTSTP rather than SIGSTOP? I think the difference is that SIGTSTP can be caught, while SIGSTOP is always an unconditional stop.

[zvrba]

That's correct.

[cyphar]

I like the use of jprobes to show the call stack within the kernel. I wish all of the tracing functionality within Linux would have one API (like DTrace). I considered writing a module to provide such an API, but there's so many complications when trying to create conditional probes (you don't have enough power with eBPF, and the default string-based globbing is useless).

[nul_byte]

I keep meaning to learn Linux from the ground up, by following the bootloader assembly, kernel initialisation etc and be able to track it in the kernel code, but its so vast I forget half of it, as I try to make my way (sporadically) through all there is.

There are so many hours in the day.

[jdub]

Or you can read Linux Insides… :-)

https://github.com/0xAX/linux-insides

[seesomesense]

Appendix A of Understanding the Linux Kernel (3rd edition) has a good overview of this.

I am trying to read this book from cover to cover while I am in hospital. It is vastly more entertaining than the cable TV.

[Razengan]

I get that feeling; I've been meaning to do that for OS X myself.

[brudgers]

Lots of good HN discussions of Linux signals:

https://hn.algolia.com/?query=linux%20signals&sort=byPopular...