How to catch signals
Steve Summit
stevesu at azure.UUCP
Sat Oct 22 09:01:45 AEST 1983
Okay, I'm cvffrq (rot13)! Nobody knows how to catch signals!
Well, maybe some people do, but whoever wrote catdvi (the program
to send troff output to an Imagen laser printer) did not. For
weeks I've been trying to figure out why my background itroff's
kept dying mysteriously. They die whenever I type control-C.
Everybody go get your Unix Programmer's Manual, Volume II. Turn
to the paper entitled "Unix Programming -- Second Edition," by
our friends Brian W. Kernighan and Dennis M. Ritchie. Look at
page sixteen, and recite...
"Why the test and the double call to signal? Recall that
signals like interrupt are sent to all processes started
from a particular terminal. Accordingly, when a program
is to be run non-interactively (started by & ), the shell
turns off interrupts for it so it won't be stopped by
interrupts intended for foreground processes. If this
program began by announcing that all interrupts were to
be sent to the onintr routine regardless, that would undo
the shell's effort to protect it when run in the background.
The solution, shown above, is to test the state of
interrupt handling, and to continue to ignore interrupts
if they are already being ignored. The code as written
depends on the fact that signal returns the previous state
of a particular signal. If signals were already being
ignored, the process should continue to ignore them;
otherwise, they should be caught."
I don't have the source for catdvi, but I disassembled it with
adb and sure enough, the very first thing it does is
signal(SIGHUP, GoAway);
signal(SIGINT, GoAway);
signal(SIGKILL, GoAway);
without the test or double call. Is anyone out there from the
Imagen company listening? In the meantime I think I'll patch the
binary. It won't be fun, but on a heavily loaded system I always
put my troff's in the background, and I'm always typing
control-C's, so I'm always getting screwed.
While you have your UPM open to the Unix Programming paper, look
at the bottom of page fourteen and read a very little-known fact
about why you always have to wait for a child process, even if
you know it's dead:
"Equally important when a process creates several
children is that only a bounded number of unwaited-for
children can exist, even if some of them have terminated;
performing the wait lays the child to rest."
If you forget the wait, your process table will fill up and
future forks will fail.
The most amazing thing about the Unix Programming paper is that
it tells you, simply and easily, how to do those hairy things
with signals and pipes and forks that you laboriously figured out
by staring at the incomprehensible man pages or by copying
somebody else's (buggy) code.
Steve Summit
Tektronix, Inc.
tektronix!tekmdp!bronze!stevesu
More information about the Comp.unix.wizards
mailing list