iTOP4412 development board operation - process communication topic | signal communication

砂舞的玩笑

iTOP4412 development board operation - process communication topic | signal communication [Copy link]

When we encounter a software that cannot be closed normally on Windows, we can open the task manager and force the process to end. Similarly, there are similar functions on Linux, such as typing ctrl+c from the terminal to generate a signal, and the running process will respond when it captures the signal.

We can use shortcut keys to enter the task manager on Windows, but under what circumstances will signals be generated in Linux?

So how many signals does Linux have? We can view them through the kill command, as shown below:

From the screenshot above, we can see that there are 64 signals in total, each signal starts with sig, and the signal name is defined in signal.h.

This article mainly involves three contents: one, signal sending, two, signal receiving, and three, signal processing.

Part 1: Signal Transmission

Let's understand the sending of signals through a small example:

This program mainly uses the kill function, because the user space does not have the ability to send signals. Only the kernel can send signals. The kernel has so many signals. Which signal should we send and to whom? Then we need to tell the kernel process PID and the signal ID first. The kill function helps us solve this problem. The function prototype is:

So in the above example, we can use the kill function to send a request to generate a signal to the kernel.

Let's look at another function that is very similar to the kill function, the raise function. Unlike the kill function, it does not have the first parameter. It does not know to whom to send the signal, so it can only send the signal to itself. Let's look at this example:

Compile and run:

Function prototype:

From the function prototypes of kill and raise, raise does not have the parameter pid, so raise can be implemented through kill. It is equivalent to:

There is another function that needs to be understood, the alarm function. Unlike the raise function, it can only send alarm signals and can send signals at a fixed time, while raise makes the kernel send signals immediately. Therefore, the parameters of this function do not have a pid number or a signal ID, but only a delay in seconds. It should be noted that a process can only have one alarm time. The function prototype is:

Summary of signal transmission in the first part:

User space cannot send signals. It is through the system call function that the kernel is told what signal to send and to whom to send it. Only the kernel can send signals. You can use the kill, raise, and alarm functions to let the kernel send signals.

Part 2 Signal Reception

We can use pause to receive signals. The pause function pauses the process and gives up the CPU. Let's look at the following example. When we press ctrl+c on the keyboard, the program will be awakened by the SIGINT signal, and then execute the fun function. After processing, it will return to continue running the program. If we do not press ctrl+c, it will only print process start (entering sleep state).

Function prototype:

Part III Signal Processing

There are three ways to handle signals: 1. Ignore, that is, do nothing after receiving the signal. 2. Process it in the default way. 3. Capture and process, after capturing the signal, execute the code we want to execute. Let's take a look at the signal function first:

The first approach is to ignore:

Let’s look at this example.

Compile and run. Because the parameter we use is SIG_IGN, we cannot interrupt the program when we press ctrl+c.

The second way to handle it is to follow the default method. We change the parameter in the previous example to SIG_DFL, as follows:

Compile and run. When we press ctrl+c, our program will be interrupted.

The third way to handle it is to execute our own code:

When we press ctrl+c, we will enter the fun function.

Summary of three parts:

1. We can use the kill command to see how many signals there are. Among so many signals, we must remember the following ones:

2. User space cannot send signals. Signals are generated by the kernel. Ways to let the kernel generate signals include: inputting ctrl+c on the keyboard, etc. When a program runs into an error, the kernel will send a signal to the process, such as floating point overflow, etc. Also, a program can send a signal to another process by calling a function, such as kill.

3. After the process receives the signal, it can ignore it, or handle it in the default way, or handle it according to its own processing function. Signale is permanently registered and valid every time. If you don't want this, you can use sigaction.