4 ms·
> Signals are a way for Unix processes to communicate! Not really. They are primarily a mechanism for processes to be interrupted by their "controlling termina
by bluetomcat 3y ago
> 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.
- hnlmorg 3y agoSignals 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.
- eesmith 3y agoFrom A Research UNIX Reader: Annotated Excerpts from the Programmer’s Manual, 1971-1986 by M. Douglas McIlroy at https://www.cs.dartmouth.edu/~doug/reader.pdf https://www.cs.dartmouth.edu/~doug/reader.pdf "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."