Inter-process communication between Linux

Pipeline

Communication that can be used only with affinity between processes is a half-duplex communication pattern,

With a fixed write-read and write-side, the pipeline can be regarded as a special kind of file, it can use ordinary read, write and other operations

Pipeline creation:

#include <unistd.h>

int pipe (int fd[2])

The two ends of the pipeline created by the function are in the middle of a process and are not significant in practice, so a process typically fork a sub-process after it is created by pipe ().

Communication between parent-child processes is then implemented through pipelines (and therefore not difficult to roll out, as long as there are affinity in two processes, where the kinship refers to having a common ancestor, which can be communicated by means of a pipeline).

The two ends of the pipe can be described by the description character Fd[0] and fd[1], and it is important to note that the ends of the pipe are fixed on the task.

That is, one end can only be used for reading, represented by the description word fd[0], which is called the pipe reading end, and the other end can only be used for writing, by the description word fd[1] to be said to be the pipe write end.

If you attempt to read data from the pipe write end, or write data to the pipe read end, it will cause an error to occur. I/O functions for general files can be used for pipelines such as close, read, write, and so on.

Read data from the pipeline: if the write end of the pipeline does not exist, it is considered that the end of the data has been read, the Read function returns the number of read bytes is 0;

When the write side of the pipeline exists, if the requested number of bytes is greater than pipe_buf, the number of existing data bytes in the pipeline is returned,

If the requested number of bytes is not greater than pipe_buf, the number of existing data bytes in the pipeline is returned (at this point, the amount of data in the pipeline is less than the requested amount of data);

or return the requested number of bytes (in this case, the amount of data in the pipeline is not less than the requested amount of data).

Note: (Pipe_buf is defined in Include/linux/limits.h, different kernel versions may vary.) The posix.1 requires that the PIPE_BUF be at least 512 bytes, or 4096).

When writing data to a pipeline, Linux does not guarantee the atomicity of writes, and the pipeline buffer has an idle area, and the write process attempts to write data to the pipeline.

If the read process does not read the data in the pipeline buffer, the write operation will be blocked. Note: Writing data to a pipeline is meaningful only if the read side of the pipeline exists. Otherwise, the default action is the application terminates.

Signal

The signal is a simulation of the interrupt mechanism at the software level, in principle, a process receives a signal that the processor receives an interrupt request can be said to be the same.

The signal is asynchronous, and a process does not have to wait for the signal to arrive by any action, in fact, the process does not know exactly when the signal arrives.

The signal is the only asynchronous communication mechanism in the interprocess communication mechanism, which can be regarded as asynchronous notification and what happens in the process of notifying the receiving signal.

After POSIX real-time expansion, the signaling mechanism is more powerful and can deliver additional information in addition to the basic notification function.

There are two sources of signal source events: hardware sources (e.g. we pressed the keyboard or other hardware failure);

Software sources, the most common system functions for sending signals are kill, raise, alarm and setitimer, and Sigqueue functions, and software sources include operations such as illegal operations.

The process can respond to a signal in three ways: (1) ignore the signal, that is, the signal does not do any processing, wherein two signals can not be ignored: Sigkill and sigstop;

(2) Capture the signal. The signal processing function is defined and the corresponding processing function is executed when the signal occurs;

(3) To perform the default operation, Linux provides a default action for each signal, please refer to the details. Note that the default response of a process to a real-time signal is a process termination.

Which of the three ways Linux responds to a signal depends on the parameters passed to the corresponding API function.

The main functions for sending signals are:

Kill ()

#include <sys/types.h>

#include <signal.h>

int Kill (pid_t pid,int Signo)

The value of the parameter PID is the receiving process of the signal

Kill () is most commonly used to send a signal when pid>0, the call returns 0 successfully; otherwise, 1 is returned.

Note: For pid<0 situation, for which process will accept the signal, various versions of the argument, in fact, very simple, see the kernel source kernel/signal.c can

Raise ()

#include <signal.h>

the int raise (int signo) sends a signal to the process itself, with the parameter being the signal value that is about to be sent.

The call returns 0 successfully; otherwise, 1 is returned.

Sigqueue ()

#include <sys/types.h>

#include <signal.h>

int Sigqueue (pid_t pid, int sig, Const Union Sigval Val)

The call returns 0 successfully; otherwise, 1 is returned. Sigqueue () is a relatively new send signaling system call,

Mainly for real-time signal (of course, also support the first 32), supporting the signal with parameters, and function sigaction () with the use.

The first parameter of the sigqueue is the process ID that specifies the receive signal, the second parameter determines the signal to be sent,

The third parameter is a federated data structure, union Sigval, that specifies the parameters of the signal passing, that is, the 4-byte value that is commonly referred to.

typedef Union SIGVAL

{

int sival_int;

void *sival_ptr;

}sigval_t;

Sigqueue () passes more additional information than Kill (), Sigqueue () can only send a signal to a process and not send a signal to a process group.

If signo=0, an error check is performed, but no signal is actually sent, and a 0 value signal can be used to check the validity of the PID and whether the current process has permission to send a signal to the target process. When Sigqueue is called, the information specified by sigval_t is copied to the 3 parameter signal processing function (3 parameter signal processing function refers to the signal processing function is installed by the sigaction and the Sa_sigaction pointer is set)

Alarm ()

#include <unistd.h>

unsigned int alarm (unsigned int seconds)

Specifically for the SIGALRM signal, after a specified time of seconds seconds, the process itself will send a SIGALRM signal, also known as the alarm time.

Any previous alarm () calls will not be valid after the process calls alarm. If the parameter seconds is zero, no alarm time is included in the process.

The return value, if the alarm time has been set in the process before alarm () is called, returns the time remaining for the previous alarm time, otherwise 0.

Setitimer ()

#include <sys/time.h>

int Setitimer (int which, const struct itimerval *value, struct itimerval *ovalue);

Setitimer () is powerful than alarm and supports 3 types of timers:

Itimer_real: Set the absolute time, after the specified time, the kernel will send SIGALRM signal to the process;

Itimer_virtual Set the program execution time, after the specified time, the kernel will send SIGVTALRM signal to the process;

Itimer_prof sets the process execution and the time that the kernel consumes due to this process and, after a specified time, the kernel sends a itimer_virtual signal to the process;

Setitimer () The first parameter which specifies the timer type (one of the three above);

The second parameter is an example of a structural itimerval, which is shown in Appendix 1 in the form of Itimerval.

The third parameter is not processed.

The Setitimer () call returns 0 successfully, otherwise returns-1.

Abort ()

#include <stdlib.h>

void abort (void);

Sends a sigabort signal to the process, by default the process exits abnormally, and of course it can define its own signal processing function.

Even if the sigabort is set to block by the process, the sigabort can still be received by the process after calling abort (). The function has no return value.

Installation of the signal

If a process is to process a signal, it must be installed in the process.

The installation signal is mainly used to determine the signal value and process for the signal value of the mapping between the action, that the process will process which signal;

What action will be performed when the signal is passed to the process.

Linux mainly has two functions for signal installation: signal (), sigaction (). Signal () is a library function that is implemented on the basis of a reliable signal system invocation.

It has only two parameters, does not support signal transmission information, mainly for the first 32 kinds of non-real-time signal installation;

Sigaction () is a newer function (implemented by two system invocations: Sys_signal and Sys_rt_sigaction), with three parameters that support signaling information, primarily for use with sigqueue () system calls, of course, sigaction ( also supports installation of non-real-time signals. Sigaction () is better than signal () mainly reflected in the supporting signal with parameters.

Inter-process communication between Linux