10.7 sigchld Definition

The two signals that are often obfuscated are sigcld and sigchld. The signal sigcld is derived from System V. The meaning of the signal is different from that of the signal sigchld originating from BSD. Posix.1 signal is also called sigchld. the meaning of sigchld from the BSD signal is normal. When the signal appears, it indicates that the sub-process status has changed. Then we need to call a wait function to check what happened.

System V's processing history of sigcld is different from other signals. The svr4i-based system maintains this problematic tradition, if we use the signal function or sigset (the function used to set the signal processing function in svr3) to set the signal processing function, early processing of sigcld includes the following actions:

1. If you specify the signal processing function as sig_ign, sub-processes that call the process will never generate zombie processes. Note that this is different from the default processing time of the signal, which is ignored in Figure 10.1. Instead, when a sub-process is terminated, the sub-process status will be discarded. If its parent process then calls one of the wait functions, the calling process will be blocked until all sub-processes are terminated, then the wait function returns-1 and errno is set to echild. (Note: The signal is ignored when the signal is processed by default, but the default processing method does not generate the above action. Instead, we must set the signal processing function to sig_ign .)

   Posix.1 does not specify what will happen when sigchld is ignored, so the above processing is also allowed, and the xsi option requires this processing to be supported by the signal sigchld.
   4.4bsd always generates zombie processes when sigchld is ignored. If we want to avoid zombie processes, we must wait all sub-processes. In svr4, as long as a signal or sigset function is called to set sigchld to sig_ign, the zombie process will never be generated. The four platforms described in this book are the same as those described in svr4.
   Using the sigaction function, we can set the sa_nocldwait flag to avoid zombie processes. This behavior is supported for the four platforms described in this book.

2. If we set the processing function of sigcld, the kernel will immediately check if any sub-process is waiting for processing. If yes, call the sigcld function immediately.

The second item above changes the way we compile the signal processing function, as will be discussed in the following example.

Example

As mentioned in section 10.4, the first thing in the signal processing function is to call the signal function again. In this way, in order to minimize the signal processing function, it is restored to the default processing time window, figure 10.6 is a program written according to this rule, but the program does not work well on the traditional system V platform, the output will be a continuous string "sigcld completed ed", which will lead to abnormal termination of the process due to stack space overflow.

1. #include"apue.h"
2. #include<sys/wait.h>
5. staticvoid sig_cld(int signo);
7. int main()
8. {
9. pid_t pid;
11. if(signal(SIGCLD, sig_cld)== SIG_ERR)
12. perror("signal error");
14. if((pid = fork())<0)
15. {
16. perror("fork error");
17. }
18. elseif(pid ==0)
19. {
20. /* child process*/
21. sleep(2);
22. _exit(0);
23. }
25. pause();/*parent process*/
26. exit(0);
27. }
29. staticvoid sig_cld(int signo)
30. {
31. pid_t pid;
32. int status;
34. printf("SIGCLD received\n");
36. if(signal(SIGCLD, sig_cld)== SIG_ERR)/*reestablish handler*/
37. perror("signal error");
38. if((pid = wait(&status))<0)/*fetch child status*/
39. perror("wait error");
41. printf("pid = %d\n", pid);
42. }

The problem with the above program is that the function signal is called at the beginning of the signal processing function, this corresponds to the second item discussed above-kernel check for any child process that requires wait for (this is true in the above program because we are processing the sigcld signal ), therefore, calls to the signal function will generate another call to the signal processing function, and the signal processing function will call the signal function in turn, so the whole process will continue to run repeatedly.
To solve the problem of the above program, we must move the call to the function signal to the wait function. In this way, we can call the signal function after capturing the termination state of the sub-process, this signal is generated only when other sub-processes terminate.

Posix.1 Declaration: When we establish the sigchld signal processing function, if there is a child process that has not been terminated by Wait, whether the signal needs to be generated is not specified, therefore, the above conditions are acceptable, but for posix.1, after the signal is generated, the signal processing function is not reset as the default function (assuming we are using the sigaction function of posix.1 to set the signal processing function ), there is no need to call the signal function again in the signal processing function. The above problem disappears.

From Weizhi note (wiz)

10.7 sigchld Definition