CSDN 21 -day Learning Challenge
Welcome to [ Linux C/C++/Python Community ] to discuss and share knowledge and technologies in Linux C/C++/Python/Shell programming, robotics, machine learning, machine vision, and embedded AI.
Signal related concepts
To learn Linux systematically, please pay attention to my free column "Linux from Xiaobai to master" .
1. The concept of signal
Signals can be seen everywhere in life, such as flare guns used in sports games, I will send you a look (you know hahaha), and so on. These signals have some things in common: first, they are simple; they cannot carry a large amount of information; third, they are sent only when certain conditions are met.
Signal is the carrier of information, an ancient and classic communication method in Linux/UNIX environment, and it is still the main communication method now. Early versions of Unix provided a signal mechanism, but it was unreliable and the signal could be lost. Both Berkeley and AT&T have made changes to the signaling model, adding reliable signaling mechanisms. but not compatible with each other. POSIX.1 standardized reliable signal routines.
2. Signal implementation mechanism
Process A sends a signal to B, and B executes its own code before receiving the signal. After receiving the signal, no matter where the program is executed, it must suspend the operation to process the signal, and then continue to execute after processing. Similar to hardware interrupts - asynchronous mode. But the signal is an interrupt implemented at the software level, and it was often called "soft interrupt" in the early days. The signal has such characteristics. Since the signal is realized by software, the means of its implementation causes the signal to have a strong delay, but for the user, the delay time is very short and difficult to detect.
All signals received by each process are essentially sent by the kernel and processed by the kernel. We nominally say that process A sends a signal to process B. In essence, the signal is generated by the kernel, sent by the kernel, and handled by the kernel. When a process receives a signal, it must process the signal unconditionally, and can choose to ignore (ignoring is also a kind of signal processing), capture, and process the default action of the signal.
3. Some trivial knowledge points related to signals
3.1 Ways to Generate Signals
- Key generation, such as: Ctrl+c, Ctrl+z, Ctrl+\
- System calls are generated, such as: kill, raise, abort
- Software conditions are generated, such as: timer alarm, setitimer
- Hardware exceptions occur, such as: illegal access to memory (segmentation fault), floating-point errors, division by 0 (except for floating-point numbers), memory alignment errors (bus errors), SIGPIPE
- Command generation, such as: kill command
3.2 Signal status
- produce:
- Delivery: Delivery and arrival process.
- Pending: The state between generation and delivery. This state is mainly caused by blocking (shielding).
3.3 Signal processing method
-
execute default action
-
ignore (discard)
-
Capturing (calling user processing functions), capturing can be said to be one of the most important reasons for learning signals. When our program generates a segment error, bus error, etc., the program will terminate abnormally. We can capture this error by capturing, and make the program not terminate.
3.4 Signal related information in PCB
The process control block PCB of the Linux kernel is a structure task_struct, in addition to including process id, status, working directory, user id, group id, file descriptor table, and signal-related information, mainly referring to blocked signal sets and pending signal set.
-
Blocking signal set: also called signal shielding word, add some signals to the set, set shielding for them, after shielding a certain signal, and then receive this signal, the processing of this signal will be postponed (after unmasking).
-
Pending signal sets:
- When a signal is generated, the bit describing the signal in the pending signal set is immediately flipped to 1, indicating that the signal is in a pending state; when the signal is processed and the corresponding bit is flipped back to 0, this moment is often very short.
- After the signal is generated, due to some reasons, it is mainly blocked and cannot be reached. The collection of such signals is called the pending signal set. The signal remains pending until the mask is released.
The pending signal set is the signal that has not been processed. The pending signal set is actually a 32-digit number, and each bit represents a signal. When the signal is generated, the corresponding bit is reversed to 1. If the signal is not Inverts back to 0 when processed, and remains 1 when processed.
The blocking signal set will affect the pending signal set. For example, if I set the No. 2 signal to 1 in the blocking signal set, that is, block the No. 2 signal, then the bit corresponding to the No. 2 signal in the pending signal set will become 1 (pending state), has been blocked in this state.
3.5 Number of signals
You can use the kill -l command to see what signals are available in the current system
There is no signal with number 0. Among them, signals 1-31 are called regular signals (also known as ordinary signals or standard signals), and 34-64 are called real-time signals. Driver programming is related to hardware, and the names of these signals are similar.
3.6 Four elements of signal
There are four elements that every signal must have:
- serial number
- name
- event
- The default processing action, the default action of the signal mainly includes:
- Term: terminate the process
- Ign: Ignore the signal, and ignore the operation of this kind of signal immediately by default
- Core: Terminate the process, generate a Core file, mainly to check the reason for the process termination, for gdb debugging
- Stop: Stop (pause) the process
- Cont: continue running the process
3.7 Signal Help Documentation
You can view the help documentation through man 7 signal to get the standard signal information table
Among the standard signals, there are some signals that have three "Values". The first value is usually valid for the alpha and sparc architectures, the middle value is for x86, arm and other architectures, and the last one is for the mips architecture. A '-' indicates that the signal has not been defined on the corresponding architecture. We mainly focus on the value in the middle.
Different operating systems define different system signals. So some signals appear in Unix systems, but also appear in Linux, and some signals appear in FreeBSD or Mac OS, but not under Linux. Here we only study the signals in the Linux system.
Note that you can see from the man 7 signal help documentation: The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored. Here, the SIGKILL and SIGSTOP signals are particularly emphasized, and they are not allowed to be ignored and captured, and only default actions can be performed. It can't even be set to block. In addition, it should be clear that the signal will be delivered (but not necessarily delivered) only when the event corresponding to each signal occurs.
