Principle of linux Signal Processing Mechanism

Linux Signal Processing Mechanism principle of signal processing mechanism: the kernel sends a soft interrupt signal to a process, which is set to correspond to the signal bit in the signal field of the Process entry. It should be added 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, otherwise, only the corresponding bit of the signal domain in the process is set, rather than the process. 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 www.2cto.com 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 will return the user State only after processing the signal (in the above example program, in step 5, after blocking is removed, print caught SIGQUIT and then print SIGQUIT unblocked, that is, before the sigprocmask is returned, the signal processing program executes). In the user mode, the process does not have any signal that has not been processed. The kernel processes the Soft Interrupt signal received by a process in the context of the process. Therefore, the process must be in the running state. 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. Only when the function returns and the top of the stack pops up will the process return the original entry to the kernel and continue running. The reason for this is that user-defined processing functions cannot and cannot be executed in the kernel state (if user-defined functions are run 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 finishes processing the interrupt signal and returns the user State, the kernel clears the address of the processing routine for the signal set 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 obtained before calling signal. In BSD, the kernel does not clear this address. However, if this 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. Note that if the signal to be captured occurs when the process is being called by a system, and the process is sleep at the priority of interruption (if the system call is not sleep but is running, according to the analysis above, wait until the system call is completed before processing the signal ), 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 the process is returned from the signal processing routine, it is like returning from the system call, but an error such as-1 is returned, and errno is set to EINTR, indicates that the system call was interrupted. Note that the inner core of the BSD system can automatically restart the system call, or manually restart the system as described above. Www.2cto.com third Note: 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. Therefore, the signal returned by functions such as pause and sleep from the suspended state must have a signal processing function. If there is no action, you can leave the processing function blank. The fourth thing to note: the processing method of the signal of the core sub-process termination (SIGCLD) is different from that of other signals. When a process ends normally or abnormally, the kernel sends a SIGCLD signal to its parent process. By default, the parent process ignores the signal, just as if it has not received the signal, if the parent process wants to obtain the termination status of the child process, use the signal function to set the confidence number processing program for the SIGCLD signal and call wait in the signal processing program. 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, nothing will be done. In fact, wait is not necessarily placed in the signal processing function. However, wait will suspend the parent process for sleep before the child process is terminated because you do not know when the child process is terminated.