Source: http://www.cnblogs.com/vamei
As mentioned in the article Linux Process Basics , Linux executes programs in units of processes. We can think of a computer as a building, the kernel is the administrator of the building, and the processes are the tenants of the building. Each process has a separate room (memory space belonging to the process), and each room is not allowed to enter by people outside the process. In this way, each process only focuses on what it is doing, regardless of other processes, and does not allow other processes to see inside its own room. This is a protection mechanism for each process. (Imagine how messy it would be with hundreds of processes always trying to interfere with each other, or hundreds of processes peeking at each other...)
However, in some cases, we need to break out of the closed room in order to communicate information with the process . For example, the kernel sees that a process is hitting a wall (hardware error) and needs to make the process aware that continuing like this will destroy the entire building. As another example, we want to let multiple processes cooperate. In this way, we need a certain means of communication. A signal is a way of conveying information to a process. We can think of a signal as a building administrator stuffing a small note into a room's letterbox. Then the process takes out a small note, and will take certain actions according to the content on the note, such as the light is broken, reminding the process to use the flashlight. (Of course, it is also possible to ignore the note completely, but in an emergency like a fire, ignoring the signal is not a good option). Compared with other interprocess communication methods (such as pipe, shared memory), the information that the signal can transmit is relatively rough , just an integer. But precisely because of the small amount of information transmitted, the signal is also easy to manage and use. Signals are therefore often used for system management related tasks, such as notifying a process of termination, abort or resume, and so on.
give me a signal
Signals are managed by the kernel. There are various ways to generate a signal. It can be generated by the kernel itself. For example, if a hardware error occurs (such as a division operation with a denominator of 0, or a segmentation fault), the kernel needs to notify a process; it can also be generated by other processes. , sent to the kernel, and then passed by the kernel to the target process. There is a table in the kernel for each process to store relevant information (the mailbox of the room). When the kernel needs to pass a signal to a process, it writes the signal (inserts a note) in the appropriate position in the table corresponding to the process, so that the signal is generated . When the process executes a system call and exits the kernel after the system call is completed, it will check the information in the mailbox by the way. If there is a signal, the process will perform the operation corresponding to the signal (signal action, also known as signal processing signal disposition), which is called the delivery signal. The time from the generation of the signal to the delivery of the signal, the signal is in a pending state (the note has not been viewed). We can also design programs that allow the spawned process to block certain signals, that is, to keep these signals in a waiting state until the process unblocks or ignores the signal.
common signal
Each integer passed by a signal is assigned a special meaning, and a signal name corresponds to the integer. Common signals are SIGINT, SIGQUIT, SIGCONT, SIGTSTP, SIGALRM, etc. These are the names of the signals. you can pass
$man 7 signal
to see more signals.
Among the above signals,
SIGINT When the keyboard presses CTRL+C to send a signal from the shell, the signal is passed to the process running in the foreground in the shell. The default action for the signal is to interrupt (INTERRUPT) the process.
SIGQUIT When the keyboard presses CTRL+\ to send a signal from the shell, the signal is passed to the process running in the foreground in the shell, and the default action corresponding to the signal is to exit (QUIT) the process.
SIGTSTP When the keyboard presses CTRL+Z to send a signal from the shell, the signal is passed to the process running in the foreground in the shell. The default action for the signal is to suspend (STOP) the process.
SIGCONT is used to notify a suspended process to continue .
SIGALRM acts as a timer , usually the program generates the signal after a certain amount of time.
Using signals in the shell
Now let's actually apply the signal. We run ping in the shell:
$ping localhost
At this point we can pass CTRL+Z to pass SIGTSTP to the process. The shell shows:
[1]+ Stopped ping localhost
We use $ps to query the PID of the ping process (PID is the room number of the ping process), in my machine it is 27397
We can signal a process with the $ kill command in the shell :
$kill -SIGCONT 27397
to pass the SIGCONT signal to the ping process.
signal disposition
In the above example, all signals take the default action of the corresponding signal. But this is not absolute. When a process decides to execute a signal, there are several possibilities:
1) Ignore the (ignore) signal, the signal is cleared, and the process itself does not take any special action
2) Default (default) operation. Each signal corresponds to a certain default operation. For example, the above SIGCONT is used to continue the process.
3) Custom operation . Also called a catch signal. Execute the operation preset in the process corresponding to the signal.
Which action a process will take depends on the programming of the process. Especially in the case of getting a signal, the program often sets up some long and complex operations (usually putting these operations into a function).
Signals are often used for system management, so their content is quite complex. In-depth understanding of signals requires a certain knowledge of Linux environment programming.
Summarize
Signal mechanism; generate, deliver, pending, blocking
signal action/dispositon; ignore, default action, catch signal
$kill