Linux signal Mechanism

Linux signal mechanism-general Linux technology-Linux programming and kernel information. The following is a detailed description. I. Signal and Signal Source

Signal nature
A signal is a simulation of the interrupt mechanism at the software level. In principle, a process receives a signal and the processor receives an interrupt request. The signal is asynchronous. A process does not have to wait for the signal to arrive through any operation. In fact, the process does not know when the signal will arrive.

Signals are the only asynchronous communication mechanism in the inter-process communication mechanism. They can be seen as asynchronous notifications to notify the processes that receive signals of what happened. After POSIX real-time expansion, the signal mechanism is more powerful. In addition to the basic notification function, it can also transmit additional information.

Signal Source
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.

Ii. Signal types
Signals can be classified from two different classification perspectives: (1) Reliability: reliable and unreliable signals; (2) Relationship with time: Real-time and non-real-time signals. All signals supported by the system are listed in Appendix 1 of "inter-process communication in Linux environment (I): pipelines and famous pipelines.

1. Reliable and unreliable Signals

"Unreliable signal"
The Linux signal mechanism is basically inherited from the Unix system. In early Unix systems, the signal mechanism was relatively simple and original, and some problems were exposed in practice. Therefore, the signals built on the early mechanism were called "unreliable signals ", signals smaller than SIGRTMIN (in Red hat7.2, SIGRTMIN = 32, SIGRTMAX = 63) are unreliable signals. This is the source of "unreliable signal. Its main problems are:

Each time a process processes a signal, it sets the response to the signal as the default action. In some cases, it may lead to incorrect signal processing. Therefore, if you do not want such an operation, you need to call signal () again at the end of the signal processing function (), reinstall the signal.

The signal may be lost, which will be detailed later.

Therefore, the unreliable signal in early unix mainly refers to the possibility that the process may make a wrong response to the signal and the possible loss of the signal.

Linux supports unreliable signals, but makes improvements to unreliable signal machines: after the signal processing function is called, you do not have to call the signal installation function again (the signal installation function is implemented in a reliable mechanism ). Therefore, the unreliable signals in Linux mainly refer to the possible loss of signals.

"Reliable signal"
With the development of time, practice has proved that it is necessary to improve and expand the original signal mechanism. Therefore, various later Unix versions were studied in this respect to achieve "reliable signals ". Because the originally defined signals have been used in many applications and cannot be modified, we have to add some new signals and define them as reliable signals at the beginning. These signals support queuing, no loss. At the same time, a new version of signal sending and installation has also emerged: the signal sending function sigqueue () and the signal installation function sigaction (). POSIX.4 standardizes reliable signal machines. However, POSIX only standardizes the functions of the reliable signal mechanism and the external interfaces of the signal mechanism, but does not specify the implementation of the signal mechanism.

The signal value between SIGRTMIN and SIGRTMAX is a reliable signal, which overcomes the possibility of signal loss. Linux supports the new version of the signal INSTALLATION function sigation () and the signal sending function sigqueue (). It also supports the early signal () signal INSTALLATION function and the signal sending function kill ().

Note: Do not misunderstand that signals sent by sigqueue () and installed by sigaction are reliable. In fact, a reliable signal is a new signal added later (the signal value is located between SIGRTMIN and SIGRTMAX). An Unreliable signal is a signal whose signal value is smaller than SIGRTMIN. The signal reliability is only related to the signal value, and is not related to the signal sending and installation functions. Currently, signal () in linux is implemented through the sigation () function. Therefore, even if the signal installed by signal () is, at the end of the signal processing function, you do not have to call the signal installation function again. At the same time, real-time signals installed by signal () Support queuing and will not be lost.

For the current two linux signal INSTALLATION functions: signal () and sigaction (), neither of them can convert the signal earlier than SIGRTMIN into a reliable signal (neither supports queuing, but may still be lost, it is still an unreliable signal) and supports queuing for signals after SIGRTMIN. The biggest difference between the two functions is that signals installed by sigaction can transmit information to the signal processing function (which is true for all signals ), however, signals installed by signal cannot transmit information to signal processing functions. The same is true for the signal sending function.

5. Signal installation (set signal Association)
If a process needs to process a signal, it must be installed in the process. The installation signal is mainly used to determine the ing between the signal value and the action of the process against the signal value, that is, the signal to be processed by the process, and the operation to be performed when the signal is transmitted to the process.

Linux mainly has two function implementation signals: signal () and sigaction (). Signal () is implemented based on reliable signal system calls and is a database function. It has only two parameters and does not support signal transmission information. It is mainly used for the installation of the first 32 non-real-time signals, while sigaction () is a newer function (called by two systems: sys_signal and sys_rt_sigaction) have three parameters that support signal transmission information and are mainly used in combination with sigqueue () system calls. Of course, sigaction () also supports non-real-time signal installation. Sigaction () is superior to signal () mainly because it supports signal parameters.

1. signal ()
# Include
Void (* signal (int signum, void (* handler) (int );

If the function prototype is not easy to understand, you can refer to the decomposition method below to understand:
Typedef void (* sighandler_t) (int );
Sighandler_t signal (int signum, sighandler_t handler ));

The first parameter specifies the signal value, and the second parameter specifies the processing of the previous signal value, which can be ignored (the parameter is set to SIG_IGN ); you can use the default signal processing method (the parameter is set to SIG_DFL), or you can implement the processing method by yourself (the parameter specifies a function address ).

IF signal () is called successfully, return the handler value when signal () is called for the last signum installation signal; If signal () fails, return SIG_ERR.

2. sigaction ()
# Include
Int sigaction (int signum, const struct sigaction * act, struct sigaction * oldact ));

The sigaction function is used to change the behavior of a process after receiving a specific signal. The first parameter of this function is the signal value, which can be any specific valid signal Except SIGKILL and SIGSTOP (define your own processing function for these two signals, will cause a signal installation error ). The second parameter is a pointer to an instance of the sigaction structure. In the instance of the sigaction structure, the processing of specific signals is specified, which can be blank, the process processes the signal by default. The third parameter oldact points to the object to save the original processing of the corresponding signal. You can specify oldact as NULL. If the second and third parameters are set to NULL, this function can be used to check the signal validity.

The second parameter is the most important, including the processing of the specified signal, the information transmitted by the signal, and the functions to be shielded during the execution of the signal processing function.