Advanced Programming in the UNIX® Environment

ptg10805159

Section 10.7 SIGCLDSemantics 333

The semantics of the BSDSIGCHLDsignal arenormal, in the sense that its semantics

aresimilar to those of all other signals. When the signal occurs, the status of a child has

changed, and we need to call one of the waitfunctions to determine what has

happened.

System V,however,has traditionally handled theSIGCLDsignal differently from

other signals. SVR4-based systems continue this questionable tradition (i.e.,

compatibility constraint) if we set its disposition using eithersignalorsigset(the

older,SVR3-compatible functions to set the disposition of a signal). This older handling

ofSIGCLDconsists of the following behavior:

1. If the process specifically sets its disposition toSIG_IGN,children of the calling
   process will not generate zombie processes. Note that this is different from its
   default action (SIG_DFL), which from Figure10.1 is to be ignored. Instead, on
   termination, the status of these child processes is discarded. If it subsequently
   calls one of the waitfunctions, the calling process will block until all its
   children have terminated, and thenwaitreturns−1witherrnoset toECHILD.
   (The default disposition of this signal is to be ignored, but this default will not
   cause the preceding semantics to occur.Instead, we specifically have to set its
   disposition toSIG_IGN.)

POSIX.1 does not specify what happens whenSIGCHLDis ignored, so this behavior is

allowed. The XSI option requires this behavior to be supported forSIGCHLD.

4.4BSD always generates zombies ifSIGCHLDis ignored. If we want to avoid zombies,

we have towaitfor our children. With SVR4, if eithersignalorsigsetis called to set

the disposition ofSIGCHLDto be ignored, zombies arenever generated. All four

platforms described in this book follow SVR4 in this behavior.

Withsigaction, we can set theSA_NOCLDWAITflag (Figure10.16) to avoid zombies.

This action is also supported on all four platforms.

2. If we set the disposition ofSIGCLDto be caught, the kernel immediately checks
   whether any child processes areready to bewaited for and, if so, calls the
   SIGCLDhandler.

Item 2 changes the way we have to write a signal handler for this signal, as illustrated in

the following example.

Example

Recall from Section 10.4 that the first thing to do on entry to a signal handler is to call

signalagain, to reestablish the handler.(This action is intended to minimize the

window of time when the signal is reset back to its default and could get lost.)We show

this in Figure10.6. This program doesn’t work on traditional System V platforms. The

output is a continual string ofSIGCLD receivedlines. Eventually,the process runs

out of stack space and terminates abnormally.