
Linux Signals – Internals - ingve
http://sklinuxblog.blogspot.com/2015/05/linux-signals-internals.html
======
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

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

~~~
cyphar
Signals are an incredibly brittle interface. Not only can you lose signals all
the time (if a signal is sent to a process while it is handling another signal
then you can lose that signal), but you lose a lot of semantic information
because the model of signal is "random callback that you jump to and you lose
your old stack state while in the signal" is incredibly lossy. There's a lot
of other problems (signals not being queueable, as well as the fact that
signals expose a bunch of kernel race conditions by design) but you get the
gist.

Unix did a lot of things right, but signals was certainly not one of them.
Sometimes the simple ideas aren't the best ones.

~~~
jcrites
> if a signal is sent to a process while it is handling another signal then
> you can lose that signal

> signals not being queueable

Are you sure? I'm not an expert on signal handling, but I believe these
statements are not true in the case of signalfd(2), which allows you to read
signals from a file descriptor and does not require a signal handler.

~~~
cyphar
Signal sending cannot block, so you'd need to have an unlimited amount of
memory in order to guarantee that all signals are delivered. Not to mention
that some signals allow you to block a process in the middle of a syscall
(resulting in the lovely restart_syscall and EINTR hacks).

Also, signalfd(2) has its own lovely host of problems (caused by the fact that
a file descriptor and signals don't match in abstractions). On fork(),
sendmsg() or exec() or any other interesting event, the file descriptor starts
to lean towards breaking POSIX. In addition, because of signals' interactions
with threads, you get some even odder interactions when you read from the fd
in a multithreaded program (they share the file descriptor table but will read
different data).

------
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](https://github.com/0xAX/linux-insides)

------
brudgers
Lots of good HN discussions of Linux signals:

[https://hn.algolia.com/?query=linux%20signals&sort=byPopular...](https://hn.algolia.com/?query=linux%20signals&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

