Linux signal Signal Processing Mechanism 2

Ii. Email System

The previous section describes the basic concepts of signals. In this section, we will introduce how the kernel implements the signal mechanism. That is, how the kernel sends signals to a process, how the process receives a signal, how the process controls its response to the signal, when the kernel processes the signal, and how it processes the signal received by the process. It also introduces the functions of setjmp and longjmp in signal.

1. Basic kernel Signal Processing Methods

The inner core sends a soft interrupt signal to a process, which is set to the bit corresponding to the signal in the signal field of the Process entry. What we need to add here is that if the signal is sent to a sleeping process, it depends on the priority of the process going to sleep. If the process goes to sleep, it will wake up the process; otherwise, only the corresponding bit of the signal field in the process is set, and the process is not wakened. This is important because the time when the process checks whether a signal is received is: when a process is about to return from the kernel state to the user State; or, when a process needs to enter or exit a proper low-scheduling priority sleep state.

The time when 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 runs in the kernel state, the soft interrupt signal does not take effect immediately and will not be processed until it returns to the user State. The process returns the user State only after processing the signal, and the process does not have the signal that has not been processed.

The Soft Interrupt signal received by a process is in the context of the process. Therefore, the process must be in the running state. As mentioned above, there are three types of processing signals: The process receives the signal and returns it; the process ignores the signal; the process receives the signal and executes the user settings to call the signal function using the system. When a process receives a signal that it ignores, the process discards the signal, as if it did not receive the signal to continue running. If a process receives a signal to capture, the process executes user-defined functions when returning the user State from the kernel state. In addition, the method for Executing User-defined functions is clever. The kernel creates a new layer on the user stack, which sets the return address value to the address of the User-Defined processing function, in this way, the process returns to the user-defined function from the kernel to the top of the pop-up stack, and then the back of the function to the top of the stack to return the original entry to the kernel. The reason for this is that the user-defined processing function cannot be executed in the kernel state (if the User-Defined Function runs in the kernel state, the user can obtain any permissions ).

Pay special attention to the signal processing methods. First, in some systems, when a process processes the interrupt signal and returns the user State, the kernel clears the address of the processing routine set for this signal in the user area, that is, the next process changes the processing method for this signal to the default value, unless it is called again by the signal system before the next signal arrives. This may cause the process to exit after the signal is called. In BSD, the kernel does not clear this address. However, if the address is not cleared, the process may obtain a signal too quickly, resulting in stack overflow. In order to avoid the above situation. In the BSD system, the kernel simulates the hardware interrupt processing method, that is, when processing an interrupt, it prevents receiving new such interruptions.

Second, it should be noted that if the signal to be captured occurs when the process is being called by a system and the process is sleep at an interrupted priority, at this time, the signal causes the process to perform longjmp, jump out of the sleep state, return to the user State, and execute the signal processing routine. When a process is returned from a signal processing routine, it is like a system call, but an error code is returned, indicating that the system call has been interrupted. Note that the BSD kernel can automatically restart the system call.

Third, note that if a process is sleep at an interrupted priority, the process is awakened when it receives a signal to be ignored, but longjmp is not performed, generally, it is to continue sleep. However, the user does not feel that the process has been awakened, but does not have this signal.

Note: The Processing Method of the sigcld signal of the kernel is different from that of other signals. When a process detects that a sub-process is terminated, the process does not receive the signal by default. If the parent process executes the system to call wait, the process will wake up from the system call wait and return to the wait call to execute a series of subsequent operations (find the zombie child process and release the child process progress table ), then return from wait. The sigcld signal is used to wake up a sleep process that can be interrupted. If the process captures this signal, it will be transferred to the processing routine like normal signal processing. If the process ignores this signal, the system calls wait for different actions, because sigcld only serves to wake up a sleep process with a priority that can be interrupted, then the parent process that executes the wait call is awakened to continue the subsequent operations of the wait call, and then waits for other child processes.

If a process calls the signal system and sets the processing method of sigcld, and a sub-process is in zombie state, the kernel sends a sigcld signal to the process.

2. Functions of setjmp and longjmp

In the previous introduction to signal processing mechanisms, setjmp and longjmp were mentioned many times, but their functions and implementation methods were not carefully described. Here is a brief introduction.

When introducing the signal, we can see that the process requires the process to directly return from the original system call after checking that the signal is received, rather than waiting until the call is completed. This process suddenly changes its context, that is, the result of using setjmp and longjmp. Setjmp saves the saved context to the user zone and continues to execute it in the old context. This means that a process executes a system call. When it goes to sleep for source or other reasons, the Kernel performs a setjmp for the process. If it is awakened by a signal during sleep, when a process cannot go to sleep, the kernel calls longjmp for the process. This operation is performed by the kernel to restore the context of the original setjmp call stored in the process user zone to the current context, in this way, the process can restore the status before waiting for resources, and the kernel returns 1 for setjmp, so that the process knows that the system call failed. This is what they do.