Linux programming signal (2): Signal Processing Process (generation, registration, logout, and execution)

For a complete signal Life Cycle (after the signal is sent to the corresponding processing function for execution), it can be divided into three phases:

• Signal Generation
• Sign up in process
• Logout of signal in process
• Signal processing function execution

1. Signal Generation

There are two sources for the occurrence of signal events: hardware sources (for example, we press the keyboard or other hardware faults); software sources, the most common system function for sending signals is kill, raise, alarm, setimer, and sigqueue functions. The software source also includes some illegal operations.

Here, we simply classify the reasons for sending signals to learn about various signals:

(1) signals related to process termination. This type of signal is sent when the process exits or the sub-process is terminated.

(2) signals related to process exception events. For example, if a process crosses the border, attempts to write a read-only memory area (such as the program body area), or executes a privileged command and other hardware errors.

(3) signals related to unrecoverable conditions during system calls. For example, when the system calls exec, the original resources have been released, and the system resources have been exhausted.

(4) signals related to non-predicted error conditions during system calls. For example, execute a non-existing system call.

(5) signals sent by processes in user mode. For example, a process call system calls kill to send signals to other processes.

(6) signals related to terminal interaction. For example, you can close a terminal or press the break Key.

(7) signal of process execution.

The signal list supported by Linux is as follows. Many signals are related to the machine architecture.

The reason why the signal value is sent by default when processing the action

SIGHUP 1 A terminal suspension or Control Process Termination

SIGINT 2 A keyboard interruption (for example, the break Key is pressed)

The exit key of the sigquit 3 C keyboard is pressed

Invalid SIGILL 4 C command

SIGABRT 6 C Exit Command issued by abort (3)

SIGFPE 8 C floating point exception

SIGKILL 9 AEF Kill signal

SIGSEGV 11 C Invalid Memory Reference

SIGPIPE 13 A pipe rupture: Write an pipe without A read Port

SIGALRM 14 A signal sent by alarm (2)

SIGTERM 15 A termination signal

SIGUSR1 30,10, 16 A user-defined signal 1

SIGUSR2, 17 A user-defined Signal 2

SIGCHLD, 18 B sub-process end signal

SIGCONT 19,18, 25 process continued (previously stopped process)

SIGSTOP 17,19, 23 DEF terminate the process

SIGTSTP 18, 20, 24 D control terminal (tty) press the stop key

SIGTTIN, 26 D background process attempted to read from control terminal

SIGTTOU, 27 D background process attempted to write from control terminal

The letter meanings in the action item are as follows:

The default action of A is to terminate the process.

The default action of B is to ignore this signal and discard it without processing.

The default action of C is to terminate the process and perform a kernel image dumping (dump core ), kernel image dumping refers to dumping the image of process data in the memory and part of the content of the process in the kernel structure to the file system in a certain format and exiting the execution, the advantage of doing so is to provide programmers with convenience, so that they can get the data value at the time the process was executed, allow them to determine the cause of the dump, and debug their program.

D. The default action is to stop the process and resume the process after it enters the stopped state. Generally, it is in the debugging process (such as ptrace System Call)

E signal cannot be captured

F signal cannot be ignored

2. register the signal in the target process

There is a soft interrupt signal field in the table of the Progress table. Each digit in the field corresponds to one signal. The kernel sends Soft Interrupt signals to a process by setting the bit corresponding to the signal field in the process's progress table. If the signal is sent to a sleeping process, if the process is sleep at the priority that can be interrupted, it will wake up the process; otherwise, only the corresponding bit of the signal in the process is set, do not wake up the process. If it is sent to a running process, set only the corresponding domain.

The task_struct structure of the process contains the data member about the pending signals in the process: struct sigpending pending:

Struct sigpending {

Struct sigqueue * head, * tail;

Sigset_t signal;

};

The Third Member is all pending signal sets in the process. The first and second members point to the beginning and end of a sigqueue-type structure chain (called "pending signal information chain, each sigqueue structure in the information chain depicts the information carried by a specific signal and points to the next sigqueue structure:

Struct sigqueue {

Struct sigqueue * next;

Siginfo_t info;

}

Signal registration means that the signal value is added to the pending signal Set sigset_t signal of the process (each signal occupies one digit, the information carried by the signal is retained to a sigqueue structure of the pending signal information chain. As long as the signal is in the pending Signal Set of the process, it indicates that the process already knows the existence of the signal, but it has not been processed yet, or the signal is blocked by the process.

When a real-time signal is sent to a process, no matter whether the signal has been registered in the process or not, it will be re-registered. Therefore, the signal will not be lost, real-time signals are also called "reliable signals ". This means that the same real-time signal can occupy multiple sigqueue structures in the pending signal information chain of the same process (each process receives a real-time signal, A structure will be allocated for it to register the signal information, and the structure will be added at the end of the pending signal chain, that is, all generated real-time signals will be registered in the target process ).

When a non-real-time signal is sent to a process, if the signal has been registered in the process (indicated by sigset_t signal), the signal will be discarded, resulting in signal loss. Therefore, non-real-time signals are also called "unreliable signals ". This means that the same non-real-time signal occupies at most one sigqueue structure in the pending signal information chain of the process.

Whether the signal is registered or not is unrelated to the signal sending function (such as kill () or sigqueue () and the signal INSTALLATION function (signal () and sigaction, only related to the signal value (signals with a signal value smaller than SIGRTMIN can be registered only once at most. signals with a signal value between SIGRTMIN and SIGRTMAX are registered as long as they are received by the process)

3. Signal execution and Cancellation

The kernel processes the Soft Interrupt signal received by a process in the context of the process. Therefore, the process must be in the running state. When it is awakened by signals or the CPU is re-acquired by normal scheduling, it will detect whether there is a signal waiting for processing when it returns from the kernel space to the user space. If a pending signal is waiting for processing and the signal is not blocked by the process, the process will unload the structure occupied by the signal in the pending signal chain before running the corresponding signal processing function.

For non-real-time signals, because only one sigqueue structure is occupied in the pending signal information chain, after the structure is released, the signal should be deleted in the pending Signal Set (the signal is canceled). For real-time signals, multiple sigqueue structures may be occupied in the pending signal information chain, therefore, the number of sigqueue structures occupied should be treated differently: if only one sigqueue structure is occupied (the process only receives this signal once ), after the corresponding processing function is executed, the signal should be deleted from the pending signals of the process (the signal is canceled ). Otherwise, the signal will be deleted from the pending signal set after all sigqueue of the signal is processed.

After all unshielded signals are processed, the system can return to the user space. For blocked signals, when unblocking is canceled, a set of procedures for performing the preceding check and processing will be executed again when the returned data is in the user space.

The time when the kernel processes the signal received by a process is when a process returns the user State from the kernel state. Therefore, when a process runs in the kernel state, the soft interrupt signal does not take effect immediately and will not be processed until it returns to the user State. The process returns the user State only after processing the signal, and the process does not have the signal that has not been processed.

There are three types of processing signals: The process exits after receiving the signal; the process ignores the signal; after receiving the signal, the process executes user settings to use the system to call the signal function. When a process receives a signal that it ignores, the process discards the signal and continues running as if it did not receive the signal. If a process receives a signal to capture, the process executes user-defined functions when returning the user State from the kernel state. In addition, the method for Executing User-defined functions is clever. The kernel creates a new layer on the user stack, which sets the return address value to the address of the User-Defined processing function, in this way, the process returns to the user-defined function from the kernel to the top of the pop-up stack, and then the back of the function to the top of the stack to return the original entry to the kernel. The reason for this is that user-defined processing functions cannot and cannot be executed in the kernel state (if user-defined functions are run in the kernel state, the user can obtain any permissions ).

Note: This article