Shulou(Shulou.com)06/02 Report--

Signal

1. Signal essence

A signal is a simulation of the interrupt mechanism at the software level. in principle, a process receives a signal in the same way as a processor receives an interrupt request. The signal is asynchronous, and 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.

Signal is the only asynchronous communication mechanism in the inter-process communication mechanism, which can be regarded as an asynchronous notification to inform the receiving process what has happened. After the real-time extension of POSIX, the function of the signal mechanism becomes more powerful, in addition to the basic notification function, it can also transmit additional information.

two。 Signal source

Signal events occur from two sources:

Hardware source (for example, we pressed the keyboard or other hardware failure)

Software sources, the most commonly used system functions to send signals are kill, raise, alarm and setitimer, as well as sigqueue functions. The software source also includes some illegal operations.

3. Types of signals

One: reliable signal and unreliable signal

Linux signaling mechanism is basically inherited from Unix system. The signal mechanism in the early Unix system is relatively simple and primitive, and then some problems are exposed in practice. therefore, those signals based on the early mechanism are called "unreliable signals", and the signals whose signal value is less than SIGRTMIN (Red hat 7.2, SIGRTMIN=32,SIGRTMAX=63) are unreliable signals. This is the source of "unreliable signal". Its main problem is that every time the process processes the signal, it sets the response to the signal as the default action. In some cases, it will result in incorrect handling of the signal; therefore, if the user does not want to do so, the user will have to call signal () again at the end of the signal handling function to reinstall the signal.

The signal may be lost, so the unreliable signal under the early unix mainly refers to the process may make the wrong response to the signal and the signal may be lost.

Linux supports unreliable signals, but improvements have been made to the unreliable signal mechanism: after calling the signal processing function, it is not necessary to re-call the signal installation function (the signal installation function is implemented on a reliable mechanism). Therefore, the problem of unreliable signal under Linux mainly refers to the possible loss of signal.

With the development of time, practice has proved that it is necessary to improve and expand the original mechanism of the signal. Therefore, various versions of Unix have been studied in this area in an effort to achieve "reliable signals". As the original definition of the signal has many applications, it is difficult to change, finally have to add some new signals, and define them as reliable signals at the very beginning, these signals support queuing and will not be lost. At the same time, there are new versions of signal transmission and installation: signal transmission function sigqueue () and signal installation function sigaction (). POSIX.4 standardizes the reliable signal mechanism. However, POSIX only standardizes the functions of the reliable signal mechanism and the external interface of the signal mechanism, and does not specify the implementation of the signal mechanism.

The signals whose signal values are between SIGRTMIN and SIGRTMAX are reliable, and the reliable signal overcomes the problem that the signal may be lost. While Linux supports the new version of the signal installation function sigation () and the signal transmission function sigqueue (), it still supports the early signal () signal installation function and the signal transmission function kill ().

Note: don't misunderstand that signals sent by sigqueue () and installed by sigaction are reliable. In fact, a reliable signal is a new signal that is added later (the signal value is between SIGRTMIN and SIGRTMAX); an unreliable signal is a signal whose signal value is less than SIGRTMIN. The reliability and unreliability of the signal are only related to the signal value and have nothing to do with the transmission and installation function of the signal. Currently, signal () in linux is implemented through the sigation () function, so even if the signal is installed through signal (), the signal installation function does not have to be called again at the end of the signal processing function. At the same time, the real-time signal installed by signal () supports queuing and will not be lost.

For the current two signal installation functions of linux: signal () and sigaction (), they can not turn the previous SIGRTMIN signal into a reliable signal (both do not support queuing, it is still possible to lose, it is still unreliable signal), and they all support queuing for future SIGRTMIN signals. The biggest difference between the two functions is that signals installed by sigaction can pass information to the signal processing function (which is true for all signals), while signals installed by signal cannot pass information to the signal processing function. The same is true for signalling functions.

Second: real-time signal and non-real-time signal

Early Unix systems defined only 32 signals, while Ret hat7.2 supports 64 signals, numbered 0-63 (SIGRTMIN=31,SIGRTMAX=63), which may be further increased in the future, which needs to be supported by the kernel. The first 32 signals already have predefined values, each signal has a definite purpose and meaning, and each signal has its own default action. If you press the CTRL ^ C of the keyboard, a SIGINT signal will be generated, and the default response to this signal is to terminate the process. The last 32 signals represent real-time signals, which are equivalent to the reliable signals described above. This ensures that a plurality of real-time signals transmitted are received. Real-time signals are part of the POSIX standard and can be used in application processes.

Non-real-time signals do not support queuing, all are unreliable signals; real-time signals support queuing, all are reliable signals.

4. Response of a process to a signal

A process can respond to a signal in three ways:

(1) ignore the signal, that is, no signal processing is done. Among them, there are two signals that cannot be ignored: SIGKILL and SIGSTOP.

(2) capture the signal. Define the signal processing function, when the signal occurs, execute the corresponding processing function

(3) perform the default operation, which is specified by Linux for each signal.

Note that the default response of a process to a real-time signal is to terminate the process.

Which of the above three ways is used by Linux to respond to the signal depends on the parameters passed to the corresponding API function.

5. Transmission of signal

One: a successful int kill (pid_t pid,int signo) call returns 0, otherwise it returns-1.

Pid > 0 process ID is a pid process

Pid=0 processes of the same process group

Pid

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.