Processes and Threads under Linux (ii)--signal

Communication between Linux processes:

This paper mainly discusses the signal problem.

As mentioned in the process and thread (a) under Linux, the Scheduler can dispatch the process in an interrupted manner.

However, how does the process know that it needs to be dispatched? A process is known to the kernel by sending a signal to the process.

The processes of the Linux system are communicated through signals.

The programmer explicitly sends a signal on the shell using the kill command , which is prototyped as follows:

Kill-sigid [-]pid

Wherein, sigid indicates that if there is a signal before the id,pid-, then the PID represents the process group ID, otherwise the PID is the process ID

The kill function also has the same effect as the prototype:

int Kill (pid_t pid, int sig);

A Typical example of using the KILL command is as follows:

When we run a foreground job on the Linux shell, the shell will fork a new process A and run our job in this new process. The foreground job may also fork child process A, sub-process B at run time.

When we press Ctrl+c,shell, we receive a SIGINT signal, and then the shell process forwards the signal to a, and a then forwards the signal to child process A, sub-process B.

Through this kind of forwarding way, to achieve signal transmission.

Excerpt from Cs:app (Figure 8-27), in the example in this book, the foreground job is running LS | Sort, shown at a glance:

It is worth mentioning that the parent process's process group ID (pgid) is the same after the child process has been created.

waiting and blocking of the signal :

If a process is processing a signal of type K, then when another K signal is reached, the pending bit vector of the process (the set of pending signals) will be set at the K bit. But this just arrived K signal will not be processed immediately until the handler program returns.

If another K-signal is present, the signal is discarded because the previous pending bit vector has been set.

Once the process receives the signal K, the kernel clears the K-bit of the pending.

The blocked bit vector (blocked signal set) maintains a signal that the process is blocked, and the signal set here is not processed by the process.

So we know that the results ofpending & ~blocked indicate the set of signals that the process is going to receive processing.

signal Interrupt Slow system call :

Slow system calls, such as read,wait,accept, block the process, and on a particular Solaris system, the blocked process will no longer return after it has been signaled. Instead, give the user an error condition and set the errno.

On a Linux system, the interrupted system call is restarted automatically.

To make the code that you write work on both Linux and Solaris systems, you write portability code.

Receive signal :

Processes receive a default behavior after each signal is received, such as when a sigkill signal is received and the process is terminated.

You can set the signal function to modify The default behavior of some signals:

sighandler_t signal (int signum, sighandler_t handler)

Where Signum is the signal to be captured, handler is the name of the function to execute after capturing the signal.

Processes and Threads under Linux (ii)--signal