stevesu@azure.UUCP (Steve Summit) (10/22/83)
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
gwyn%brl-vld@sri-unix.UUCP (10/25/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> Good point -- the Unix Programming paper contains much valuable information on writing decent C code for UNIX instead of the sloppy cruft that we see so much of. Too bad so many programmers can't be bothered to read good advice from the UNIX originators.