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

Today, when I read the sigal.c processing section of the book "complete Analysis of the linux Kernel-based on the 0.12 Kernel", I found that I didn't have a good understanding of the signal mechanism, so I wrote it down by consulting the data.

Several concepts:

1) what is the signal:

A signal is a message that informs the process that a certain type of event has occurred in the system.

When the user presses some keys at the terminal, the terminal driver will send a signal to the foreground process; for example, ctrl-c generates SIGINT signal; ctrl-\ generates SIGQUIT signal; ctrl-z generates SIGSTP signal

Hardware anomalies generate signals; these signals are detected by the hardware and notify the kernel, and the kernel notifies the current process, such as a division zero error in the current process

Kill system call, one process can call kill to send a signal to another process

The kernel may also signal a process when it detects that a certain software setting condition occurs, such as an alarm system call.

2) blocking signal, signal to be processed:

Blocking signal means that a process blocks one or more signal sets; blocking does not mean that the process does not receive the specified signal set; it means that the signal can still be received by the process (put into the signal set to be processed), but not processed. It can be well understood from the specific implementation of the kernel.

The kernel maintains process signal blocking vector (block) and pending vector (signal set to be processed) in task_struct; block corresponds to pending one by one, and for a certain signal: if pending corresponds to bit setting and block is reset, the identification signal has been generated and received and is not currently blocked by the process, and can be processed immediately (default or user-defined signal processing function) If pending is reset to bit and block is set, the identification signal has not been received, even if it is received, it is blocked by the current process (that is, it is not processed immediately and can only be processed after contact blocking). No, no, no.

3) minor problems in signal processing:

The pending signal may be blocked: if the current process captures a SIGINT signal and is currently running a handler for that signal, then if another SIGINT signal is passed to the process, the SIGINT will become unprocessed until the handler returns.

Signals to be processed are not queued: my understanding is related to kernel implementation (kernels generally use bit vectors to identify signal sets), as if there are real-time signal sets in linux that can be queued (learn later when you see it. )

System calls can be interrupted: generally for slow system calls, interrupted slow system calls no longer continue when the signal processor returns, but immediately return an error condition to the user and set errno to EINTR

4) Portable to signal processing program

The semantics of portable signals are as follows:

Only the type of signal that this handler is currently processing is blocked.

As all signals are implemented, the signal does not wait in line

Whenever possible, interrupted system calls are restarted. (user implementation: explicitly loop system calls; kernel implementation: restore system call parameters and let eip in the user stack re-point to system call interrupt instructions;)

Once the signal handler is set, it remains until it is reset.

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.