Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the Linux signal processing mechanism". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the Linux signal processing mechanism".

A signal is an asynchronous soft interrupt, and the kernel sends some asynchronous events to the process, which may come from hardware, such as dividing by 0 or accessing an illegal address, or from other processes or user input, such as ctrl+c.

Signal is an inter-process communication mechanism, and all signals have a corresponding default processing behavior. when the signal is triggered, the signal processing function and the normal execution flow of the process exist at the same time, which will bring hidden trouble to programming. if the non-reentrant function is called in the signal processing function. Compared with other inter-process communication technologies (pipeline, shared memory), the information transmitted by the signal is still limited, and it is easy to manage because of less information. It is generally used in system management, such as terminating or resuming the process.

The default processing operations for signals are:

Explicitly ignore the signal: that is, the kernel will discard the signal and the signal will have no effect on the target process.

Terminate the process: the default processing of many signals is to terminate the process, that is, to kill the process.

Generate a core dump file and terminate the process: the process is killed and a core dump file is generated. The core dump file records the information at the death site of the process. Users can use the core dump file to debug and analyze the cause of process death.

Stop the process: stopping the process is different from terminating the process, terminating the process means that the process is dead, but stopping the process is just pausing the process, setting the state of the process to TASK_STOPPED, and once receiving the signal to resume execution, the process can continue to execute.

Resume the execution of the process: corresponding to stopping the process, some signals can make the process resume execution.

If you want to customize the signal processing logic, you can use the signal/sigaction function interface to set the signal processing function.

Linux signals can be divided into two categories: reliable signals and unreliable signals, all signals with signal values between [1djm 31] are called unreliable signals, and signals between [SIGRTMIN,SIGRTMAX] are called reliable signals. How is it realized between the two?

For an unreliable signal, the kernel uses a bitmap to record whether the signal is suspended. If an unreliable signal is received and the kernel finds that the signal is already in a pending state, it will simply discard the signal. Therefore, if an unreliable signal is sent, the signal may be lost, that is, the number of times the kernel is delivered to the target process may be less than the number of times the signal is sent. For reliable signals, there is a queue within the kernel to maintain, and if a reliable signal is received, the kernel will hang the signal in the corresponding queue, so it will not be lost. Strictly speaking, the kernel also has an upper limit, and the number of suspended signals cannot be increased indefinitely, so it can only be said that reliable signals will not be discarded within a certain range.

The signal pending state refers to the time from the signal generation to the execution of the information processing logic.

Common Linux signals are as follows (you can view them with the command kill-l):

The SIGHUP 1 terminal suspends or controls the process to terminate. When the user exits the Shell, all processes started by the process will receive this signal, defaulting to the action as the termination process.

The SIGINT 2 keyboard is interrupted. When the user presses the key combination, the user terminal sends this signal to the running program started by the terminal. The default action is to terminate the process.

The SIGQUIT 3 keyboard exit key is pressed. When the user presses or combines the keys, the user terminal sends this signal to the running program started by the terminal. The default action is to exit the program.

Issued when a fatal computational error occurs in SIGFPE 8. It includes not only floating-point operation errors, but also all algorithm errors such as overflow and divisor 0. The default action is to terminate the process and generate a core file.

SIGKILL 9 unconditionally terminates the process. When the process receives the signal, it terminates immediately without cleanup and temporary storage. This signal cannot be ignored, processed, or blocked, and it provides the system administrator with a way to kill any process.

The SIGALRM 14 timer expires and defaults to action as the termination process.

The SIGTERM 15 program end signal can be generated by the kill command. Unlike SIGKILL, SIGTERM signals can be blocked and terminated so that the program can save work or clean up temporary files before exiting.

Timing of signal execution

Each process has a corresponding "signal table". When the kernel passes a signal to the process, the signal is written in the corresponding signal table of the process. When the process switches from kernel state to user state, the signal table is checked. If there is a signal, signal processing logic is executed. During the period from signal generation to the execution of signal processing logic, the signal is pending.

During the signal processing function, it is possible to receive other signals, and of course, it is also possible to receive the signal being processed again. What happens if the A signal is received again during the processing of the A signal?

For the traditional System V signal mechanism, the corresponding signal is not shielded during the signal processing, which will lead to the reentry of the signal processing function. This is another drawback of the traditional System V signaling mechanism. BSD signal processing mechanism corrects this flaw. Of course, the BSD signal processing mechanism only blocks the current signal, not anything other than the current signal.

Signals and threads

At present, most processes are multithreaded. If you signal a multithreaded process, which thread will handle it?

Note that signal processing belongs to the process dimension, we all know that each thread can have its own signal mask, under the POSIX standard, the signal sent to the process will be randomly selected among some thread under the process that does not block the signal. If the default behavior of the signal is to terminate the operation, then all threads will game over, not just the one that received the signal.

Note that the semaphores discussed here are not the same thing as semaphores in Java. Semaphore semaphores in Java are used to control the number of threads accessing a particular resource at the same time, and it ensures reasonable use of common resources by coordinating each thread. Semaphore can be used for traffic control, especially in application scenarios where public resources are limited, such as database connections.

Thank you for your reading, the above is the content of "what is the Linux signal processing mechanism". After the study of this article, I believe you have a deeper understanding of what the Linux signal processing mechanism is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.