Asynchronous communication mechanism in Linux kernel--signal processing mechanism __linux

What is asynchronous communication. Simply, once the device is ready, the application is proactively notified, in which case the application does not need to query the device state, as the "broken concept" is often mentioned on the hardware. The more accurate version should be called "signal-driven asynchronous I/O", a signal is a simulation of the interrupt mechanism at the software level. Blocking I/O means waiting for the device to access again, non-blocking I/O means using poll () to query for accessibility, while asynchronous communication means that the device notifies the application itself to be accessible.

I. Asynchronous mechanism in the system

I think the asynchronous mechanism is an idea, not a specific implementation, synchronous/asynchronous core understanding should be how to get the message of the problem, you (in the computer, of course, the process itself) to get the message, then the synchronization mechanism, but if someone in some way notify you of a certain message, So what you're using is the asynchronous mechanism. The kernel uses an asynchronous mechanism in the form of a signal, which is an asynchronous mechanism for interprocess communication; Epoll, an asynchronous communication mechanism that efficiently handles IO. That is, the asynchronous mechanism is used in different ways from two aspects of communication and IO.

Let's get down to business:

Ii. The basic concept of signal

1) The nature of the signal

Soft interrupt signals (signal, also referred to as signals) are used to inform the process that an asynchronous event has occurred. At the software level is a simulation of the interrupt mechanism, in principle, a process received a signal and the processor received an interrupt request can be said to be the same. The signal is the only asynchronous communication mechanism in the interprocess communication mechanism, a process does not have to wait for the signal to arrive by any operation, in fact, the process does not know exactly when the signal arrives. Processes can send soft interrupt signals to each other through system call kill. The kernel can also send a signal to the process because of an internal event, notifying the process that an event has occurred. In addition to the basic notification function, the signaling mechanism can also pass additional information.

The process of receiving signals has different processing methods for various signals. Processing methods can be divided into three categories: the first is a similar interrupt handler, for the signal to be processed, the process can specify the processing function, which is handled by the function. The second approach is to ignore a signal and do nothing with the signal, as if it had not happened.

The third method is that the processing of the signal retains the default value of the system, which, by default, is the default operation for most of the signals, which causes the process to terminate. The process specifies the processing behavior of a signal by a process through system call signal.

In the table entry of the process table, there is a soft interrupt signal field in which each digit corresponds to a signal, and when a signal is sent to the process, the position is located. It can be seen that the process can keep different signals at the same time, but for the same signal, the process does not know how many have come before processing.

2 Type of signal

The signals can be categorized from two different classification angles:

Reliability: Reliable signal and unreliable signal;

In relation to time: real-time signal and non-real-time signal.

3 reliable signal and unreliable signal

The Linux signaling mechanism is essentially inherited from Unix systems. In the early Unix system, the signal mechanism is simple and original, the signal value is less than sigrtmin signal is unreliable. This is the source of "unreliable signals". Its main problem is that the signal may be lost.

With the development of time, the practice has proved that it is necessary to improve and expand the original signal mechanism. As the original definition of the signal has many applications, not to make changes, and eventually have to add a number of new signals, and at the outset to define them as reliable signals, these signals support queuing, not lost.

Signals that are located between Sigrtmin and Sigrtmax are reliable signals, and reliable signals overcome the problem of possible loss of signals. Linux supports the early signal () Signal installation function (Sigation) while supporting the new version of the signal installation function () and the signal-sending function sigqueue (), and supports the signal-sending function kill ().

The reliability and unreliability of the signal are only related to the signal value, which is independent of the signal sending and installing function. The current signal () in Linux is implemented through the sigation () function, so even if the signal is installed through the signal (), there is no need to invoke the signal installation function at the end of the signal processing function. At the same time, the real-time signal support installed by signal () is queued and will not be lost.

For the current Linux two signal installation functions: signal () and sigaction (), neither of them can turn the previous signal of sigrtmin into a reliable signal (neither support queue, still can be lost, still unreliable signal), And the sigrtmin signals are supported in line. The biggest difference between the two functions is that the signals that are installed through the sigaction can transmit information to the signal processing function, while the signal installed signal cannot pass the message to the signal processing function. The same is true for signal-sending functions.

4 Real-time and non-real-time signals

The early UNIX system defined only 32 signals, the first 32 signals had predefined values, each signal had a defined purpose and meaning, and each signal had its own default action. If you press the CTRL ^c of the keyboard, a SIGINT signal is generated, and the default response to the signal is that the process terminates. The last 32 signals represent real time signals, equivalent to the reliable signals described previously. This ensures that multiple real-time signals sent are received.

Non-real-time signals do not support queuing, are unreliable signals, real-time signal support queuing, are reliable signals.

5 The life cycle of the signal under Linux is as follows:

Install the signal in the destination process. That is, set the opcode that the process process should execute when the signal is captured. Implemented using signal (); Sigaction () system calls.
The signal is generated by a process, and the target process of the signal is set (using PID), which is then administered to the operating system. Implemented by system calls such as Kill (), arise (), alarm ().
The signal is registered in the purpose process. The signal is added to the process's PCB (TASK_STRUCT) in the associated data structure--the data member of the pending signal. The signal is registered in the process by adding the signal value to the pending signal set of the process.
Also, other information carried by the signal is kept in a sigqueue structure in the queue of the pending letter.
The signal is logged out in the process. Before performing a signal processing function, log the signal out of the process. For Non-real-time signals (unreliable signals), there is at most one sigqueue structure in the signal information chain, so the corresponding signal is removed from the pending signal set when the structure is released. In the case of a real-time signal (a reliable signal), if there are multiple sigqueue, the signal is not removed from the pending signal set of the process.
Signal the end of life. The process terminates the current work, protects the context, executes the signal processing function, and then replies. If the kernel is preempted, then scheduling is also required.

third, signal mechanism

The basic concept of the signal is described in the previous section, and in this section we will describe how the kernel implements the signaling mechanism. How the kernel sends a signal to a process, how the process receives a signal, how the process controls its response to the signal, what time the kernel is processed, and how it processes the signal it receives. Also introduce the role of setjmp and longjmp in the signal.
1, the kernel of the basic signal processing methods

The kernel's method of sending a soft interrupt signal to a process is to set the bit in the signal field of the process table entry that corresponds to the signal. It is added that if the signal is sent to a sleeping process, it is up to the priority of the process to sleep, and if the process sleeps at a level that can be interrupted, the process is awakened, otherwise only the corresponding bits of the signal field in the process table are set, without waking the process. This is important because the process checks whether the signal is received at a time when a process is about to return from the kernel state to the user state, or when a process wants to enter or leave an appropriate low scheduling priority sleep state.

The time the kernel processes the signal received by a process is when a process returns the user state from the kernel state. Therefore, when a process is running in the kernel state, the soft interrupt signal does not immediately work, and it is not processed until the user state is returned. The process returns the user state only after processing the signal, and the process does not have an unhandled signal in the user state.

The kernel processes a process that receives a soft interrupt signal that is in the context of the process, so the process must be in a running state. Before introducing concepts, there are three types of processing signals: the process receives the signal and exits; the process ignores the signal; The process receives the signal and executes the function that the user sets the system to call signal. When a process receives a signal it ignores, the process discards the signal, as it continues to run without receiving the signal. If the process receives a signal to be captured, the process executes the user-defined function when it returns the user state from the kernel state. And the way to execute user-defined functions is ingenious, the kernel creates a new layer on the user stack that sets the value of the return address to the address of the user-defined handler function, so that the process returns to the user-defined function from the kernel when it returns to the top of the stack, returning from the function to the top of the stack, Before returning to the place where the kernel was originally entered. The reason for this is that user-defined processing functions cannot and are not allowed to execute in a kernel state (if a user-defined function is running in a kernel state, the user can gain any permissions).

There are several special points to be taken into consideration in the signal processing method. First, in some systems, before a process finishes processing the interrupt signal to return to the user state, the kernel clears the address of the processing routine for the signal that is set in the user area, that is, the next process will change the signal processing to the default value, unless the signal system call is used again before the next signal arrives. This may cause the process to exit before it calls signal before it gets the signal. In BSD, the kernel no longer clears the address. But not clearing the address may cause the process to overflow with a stack that is too fast to get a signal. In order to avoid this situation. In the BSD system, the kernel simulates the processing of a hardware interrupt that prevents a new interrupt from being received while processing an interrupt.

The second note is that if the signal to be captured occurs when the process is in a system call, and the process sleeps at an interruptible priority, the signal causes the process to perform a longjmp, jump out of sleep, return to the user state and execute a signal-processing routine. When returned from a signal processing routine, the process is like returning from a system call, but returns an error code indicating that the system call was interrupted. It should be noted that the kernel of the BSD system can automatically restart system calls.

The third thing to note: If the process sleeps on an interruptible priority, then when it receives a signal to ignore, the process wakes up, but does not do longjmp, and generally continues to sleep. But the user does not feel that the process has been awakened, but rather as if it had not happened.

The fourth point to note is that the kernel process termination (SIGCLD) Signal processing method is different from other signals. When a process checks to receive a signal that a child process terminates, by default, the process is like not receiving the signal, and if the parent process executes the system call wait, the process wakes up from the system call wait and returns a wait call to perform a sequence of wait calls (to find the zombie subprocess, Releases the process table entries for the child process, and then returns from the wait. The function of the SIGCLD signal is to awaken a sleep in a process that can be interrupted at priority level. If the process captures this signal, it will go to the processing routine like normal signal processing. If the process ignores the signal, then the action of the system call wait is different, because the function of the SIGCLD is simply to awaken a sleep to a process that can be interrupted, the parent process that executes the wait call is awakened to continue the subsequent operation of the waiting call, and then waits for the other child processes.

If a process invokes the signal system call and sets the SIGCLD processing method, and the process has a child process in a zombie state, the kernel sends a SIGCLD signal to the process. 2, the role of setjmp and longjmp

In introducing the signal processing mechanism, setjmp and longjmp are mentioned several times, but their roles and implementation methods are not carefully explained. Here is a brief introduction to this.

When introducing a signal, we see several places where a process is required to return directly from the original system call after checking for a signal, rather than waiting for the call to complete. The situation in which this process suddenly changes its context is the result of using setjmp and longjmp. SETJMP saves the context to the user area and continues execution in the old context. This means that the process performs a system call, and when sleep is due to resources or other reasons, the kernel makes a setjmp of the process, and if the signal wakes up during sleep and the process can no longer go to sleep, the kernel calls longjmp for the process, which is the kernel The context in which the process saves the original setjmp call to the process user area is restored to the current context, so that the process can recover the state before the resource is waiting, and the kernel returns 1 for setjmp, which makes the process aware that the system call failed. That's how they work.