How to catch signals

[Steve Summit]

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