I know this has been said before, but I absolutely love Julia's style of writing. It's humble and accessible, and full of great humor that is always good natured, as opposed to the more common snarky or negative humor:
> Signals are a way for Unix processes to communicate! Except for SIGKILL. When you get sent SIGKILL nobody communicates with you, you just die immediately.
It's refreshingly earnest and twee, and always technical and to the point (as opposed to other vacuous and rambling bloggers).
Also, it's reassuring to see someone say "I don't know this"/"I'm not sure", instead of trying to pass as an authority on the subject. We all learn together.
Also not communication as it can't be ignored and your process just pauses, if you consider it a thing in its own right.
Really though it is a pair with SIGCONT which is communication: SIGSTOP happens (which your process doesn't even see) then later SIGCONT happens which you do get notified about (“hey, process, you were just paused for a bit, you might want to reassess your surroundings”). This is little different from the scheduler not giving your process any time for a while, what difference there is being the while could be a lot longer and you get explicitly told that it has happened.
The other possibility is that your process never wakes up because a SIGKILL happens first. Or maybe SIGTERM, I'm not sure whether or not a SIGCONT will be sent first in that instance.
There is also the friendlier SIGSTSP which can be handled (or even ignored) but is otherwise identical to SIGSTOP. This is what you get sent if a user hits ctrl+z in most interactive shells (or a more polite process than one that just sends SIGSTOP wants you to pause).
> Signals are a way for Unix processes to communicate!
Not really. They are primarily a mechanism for processes to be interrupted by their "controlling terminal", inherited from the shell (the session leader). User types something special on the TTY, the kernel translates it to SIGxxxx and the foreground process is interrupted or killed, possibly returning control to the shell.
"In v1 there was a separate system call to catch each of interrupt, quit, and two kinds of machine traps. Floating point hardware (v3) brought another and no end was in sight. To stop the proliferation, all traps were subsumed under a single system call, signal (v4). The various traps were given numbers, by which they were known until symbolic names were assigned in v7. We have not been fully weaned yet: the numbers are still needed in the shell trap command."
Regarding communications it adds:
"Never, however, was the basically unstructured signal-kill mechanism regarded as a significant means of interprocess communication. The research systems therefore declined to adopt the more reliable, but also more complex, Berkeley signals."
Signals neither have to originate from a controlling shell and nor do that have to relate to job control.
And even if your point was correct, that still wouldn’t mean that signals aren’t a way for processes to communicate. Job control relies upon IPC to work and signals are just one form of IPC.
