UNIX question

[Dave Martindale]

In article <2548 at umcp-cs.UUCP> chris at umcp-cs.UUCP (Chris Torek) writes:
>Anyway, what it all boils down to is that process control is
>unreliable in many versions of Unix, but can be made reliable in
>4.1, 4.2, and 4.3BSD.  If there is any way to reliably handle
>process exit and `job control' style processing in System III and
>System V, I am not aware of it---though that should be unsurprising
>since I have never used them.  If it is possible in the latest AT&T
>Unixes, I would like to know how.

(My only experience with system V is on an IRIS workstation, which is system
V with some Berkeley stuff.  But the signal mechanism seems to be from
System V - there is none of the Berkeley sigmask stuff.)

On the IRIS, if you read the fine print, you will find that SIGCLD
doesn't behave like a "normal" signal.  It seems that SIGCLD is generated
by the presence of a zombie child, not the event of a child terminating.
This was brought home to me in a program that had a single child.  When
the child terminated, the SIGCLD handler (due to me not understanding
what was going on) re-enabled the signal before waiting for the child.
Immediately, another SIGCLD was delivered, and so on until the stack
overflowed.

So, if you had a second child exit while handling the first SIGCLD, no
problem - you'll get another SIGCLD as soon as you re-enable the signal.

It is also unlike a "normal" signal in that the "default" action is
for nothing to happen, while a "normal" signal causes some action beyond
the control of the process.

The essential difference, I think, is simply that V7 signals had no
"memory" - when one was delivered, either you caught it or you ignored
it and it went away, but you couldn't "hold" it.  4.2 signal handling
knows about signals that are held for later delivery.  SV doesn't
have this in general for signals, but in the case of SIGCLD the
existence of the zombie process provides the "memory".

	Dave Martindale