Linux environment Programming signals (II): Unreliable signals, interrupted system calls, reentrant functions

(i) Unreliable signals

The signal to the front is unreliable, and unreliable means that the signal may be lost: a signal has occurred, but the process may have been unaware of it. In addition, the process has limited control over the signal and can only capture the signal or ignore it. Sometimes the user wants to notify the kernel to block a signal: Do not ignore it, remember it when it occurs, and then notify it when the process is ready. The ability to block signals is not available.

The previous version of the village. A problem: The signal action is reset to its default value each time the process receives a signal to handle it. Another problem is that when a process does not want a signal to occur, it cannot turn off the signal. All the process can do is ignore the signal.

(ii) interrupted system calls

If a process captures a signal during a slow system call while blocking, the system call is interrupted and no longer continues execution. The system call returned an error and its errno was set to Eintr. The reason for this is that the process captures it because a signal has occurred, which means something has happened, so it's a good chance to wake up the blocked system call.

To support this feature, system calls are divided into two categories: low-speed system calls and other system calls. A class of system calls that can cause a process to block indefinitely when a low-speed system is called. The problem associated with the interrupted system call is that it must be displayed to handle an error return. The typical code is as follows:

Again:if ((n = Read (FD, buf, buffsize)) < 0) {if (errno = = eintr) goto again;}

In order to help the application make it unnecessary to handle interrupted system calls, some automatic reboots of the interrupted system calls are introduced. One reason to introduce an automatic restart is that sometimes the user does not know whether the input or output device being used is a low-speed device. If the program we write can run interactively, it may read and write to low-speed terminal devices. If the signal is captured in the program and the system does not provide a restart function, the test is returned for each read and write system call, and if it is interrupted, then the read and write system call is called.

(c) Reentrant function

When a process captures a signal and processes it, the sequence of instructions being executed by the process is temporarily interrupted by the signal handler, which first executes the instruction in the signal handler. If returned from the signal handler, proceeds to the normal sequence of instructions that the process is executing when the signal is snapped.