In that year, it was potentially dangerous to learn Linux C-signal processing step by step !!!

This series of articles prepared by muge0913, reproduced please indicate the source: http://blog.csdn.net/muge0913/article/details/7337737

As the communication mode of asynchronous processes, signals are convenient and practical in practical application. However, we should also note the potential risks when using signals. This section briefly introduces several situations that may cause errors, and we hope to pay special attention to the actual signal processing.

 

When a signal processing function is registered, some system calls may be modified. Generally, they should not be affected by the signal, but because a signal processing function is registered, the system may think that the original system call needs to be interrupted when a signal arrives. When this happens, the original system call is terminated, the call failure value is returned, and errno is set to eintr. Of course, in some cases, the system is indeed expected to handle this, but in other cases, it is not expected to do this, the returned error code may make the subsequent process unable to proceed in the desired direction. It may even be deemed that the call is successful because no corresponding processing is performed on the returned error in the subsequent operation, this leads to data loss. Therefore, we recommend that you use the sigaction function.
Set the sa_restart flag to prevent this situation.

In another case, another signal may be generated when you execute the signal processing function set by the user. In this case, the first call may be interrupted and the second signal processing function call may occur. When the second call ends, the execution of the first call will continue. This will affect the function running, especially for programs that use static variables. In this case, you can call the sigaction function to set sa_nodefer to block the second signal.

 

In addition, in a busy system, operations involving system time may be different from the expected results. For example, if the pause function is called after alarm, you want to end the pause status when the alarm set by alarm occurs. However, because the system is too busy, this process has too few time slices. When an alarm occurs, the pause function has not been called yet, when the pause function is called, the process may be suspended permanently.

----- (From the Linux environment C Programming Guide)