Sinsing analysis of Signals in Linux

To say the signal in Linux, you have to mention the concept of interruption. Interrupts are responses to asynchronous events in the system, which means that a process can be interrupted during the execution of the code, which first executes an exception handler. Interrupts can be broken down into hardware interrupts, which are external interrupts, which are generated by the way an external device is requested by the hardware. Software interrupts, which are internal interrupts, are some of the errors that are caused by the CPU to run the program or to perform an internal program call.

At the CPU level to see interrupts, is one such step: ① interrupt source to send interrupt signal ②cpu judgment is to shield the interrupt and the field Protection ③CPU query Interrupt vector table, locate the corresponding service program's entry address, and then execute the interrupt handler ④ interrupt processing, resume the scene, continue to perform the original task

Signals and interrupts are very similar, but the signal is an event generated by the *nix operating system in response to certain conditions, and the process takes action after receiving the signal, which can be interpreted as a simulation at the software level. The similarity between signal and interrupt is mainly: ① use the same asynchronous communication mode, ② when signal or interrupt request is detected, the current program will be paused to execute the corresponding handler, ③ return to the original breakpoint after execution ④ we can block the signal and interrupt.

The main difference between signal and interrupt is: ① interrupt has priority, but signal is not priority. ② signal processing is run in the user state, and interrupt processing is run in the kernel mentality. The ③ interrupt is timely because it is processed directly by the CPU, and the signal response usually has a large time delay.

Linux signaling mechanisms are inherited UNIX systems, the early UNIX signal mechanism is not perfect, may cause the process to make a wrong response to the signal and the signal may be lost. The signal mechanism is improved under Linux, and the main problem with Linux is that the signal may be lost. The signals that may be problematic are unreliable signals.

In order to achieve reliable signal, but also for forward compatibility, and later added a number of signals, these signals are reliable signals, these signals support queuing, not lost. Early Unix defined only 31 signals, while linux3.x defined 64 signals, numbering from 1 to 64. The previous 31 signals have predetermined values, the purpose and meaning of each signal are determined, and they all have a corresponding default action. The 32 signals in the back represent real-time signals, which are known as reliable signals, which ensure that multiple real-time signals are received and that real-time signals are part of the POSIX. Notable non-real-time signals do not support queueing, are unreliable signals, and real-time signals are supported queuing, are reliable signals.

After the signal is emitted, when the signal is executed the processing action is called the signal recursion, and the signal from the generation to the time between the delivery, known as the signal is pending. The process can block a signal, the blocked signal from the generation has been in a pending state, until the process has lifted the signal blocking, the signal will be able to perform the recursive action.

It is important to note that blocking is different from ignoring. When the signal is blocked, it does not pass, and ignoring it is a processing method after the recursion.

Sinsing analysis of Signals in Linux