How Linux processes communicate with each other

Process in the coordination of the kernel to communicate with each other, mainly including three kinds of methods: signal , pipe and socket interface three categories.

1) Signal

2) Pipeline

3) Sockets: Message Queuing, semaphores, and shared memory

Signal

Signaling is the oldest form of interprocess communication in UNIX systems. They are used to send asynchronous event signals to one or more processes. Signal can be generated from the keyboard interrupt, in addition to the process of virtual memory illegal access and other system error environment will also have a signal generation. The signal is also used by the shell program to send task control commands to its child processes.

The

  system has a set of signal types that are defined in detail, which can be generated by cores or other processes with appropriate permissions in the system, as shown below
  1) SIGHUP 2) SIGINT 3) Sigquit 4) Sigill
  5) SIGTRAP 6) Sigiot 7) Sigbus 8) SIGFPE
  9) SIGKILL) SIGUSR1 One) (SIGSEGV) SIGUSR2
  13) sigpipe () sigalrm) SIGTERM) SIGCHLD
  18) sigcont) SIGS TOP) SIGTSTP (sigttin
  22) Sigttou) Sigurg) sigxcpu) Sigxfsz
  26) sigvtalrm 27) Sigprof sigwinch) SIGIO
  30) SIGPWR
  Common signal one is the sigstop signal that causes the process to terminate execution, and the other is the sigkill signal that causes the process to exit. As for the other signals, the process can choose the specific way to handle them. A process can block a signal, and if it does not, it can choose between processing the signal itself and handing it over to the core processing. If the signal is handled by the core, it will use the default processing method corresponding to this signal. For example, when a process receives a SIGFPE (floating-point exception, which may have been encountered in the first learning program), the core default action is to cause core dump and process exit. The signal has no inherent relative precedence. If two signals are generated for a process at the same time, they may reach the process in any order and process it.

Not every process in the system can send a signal to all other processes: only the core and Superuser have this permission. A normal process can only send signals to processes that have the same UID and GID, or processes in the same process group. If the processing of the signal is set to the default then the kernel will handle it. The default process for SIGSTOP signals is
Change the state of the current process to stopped and run the dispatch manager to select a new process to continue running. The default process for SIGFPE is to cause the core dump and to exit the process. Of course, a process can define its own signal processing process.

For signal programming, you can refer to the UNIX environment Advanced Programming book.

Pipelines (including FIFO piping)

generic Linux shell programs allow redirection, for example: PS aux | grep Oracle.

   in Linux, pipelines are implemented by pointing to two file data structures that point to the same temporary VFS Inode, which points to a physical page in memory. Each file data structure points to a different document manipulation routine vector, one that implements the write to the pipeline, and the other reads from the pipeline. This hides the difference between a read-write pipeline and a system call when reading and writing plain files. When the write process writes to the pipe, the bytes are copied to the shared data page, and the bytes are copied from the shared data page when the read process reads from the pipeline. Linux must synchronize access to the pipe. It must ensure that the reader and the writer are executed in a determined step, which requires the use of a synchronization mechanism such as locks, wait queues, and signals.
     When a writer wants to write to a pipe, it uses a standard write library function. Represents a descriptor for opening a file and opening a pipeline to index a collection of file data structures for a process. The Linux system call uses the write procedure pointed to by the pipe file data structure. This write process manages write requests with information stored in the VFS inode that represents the pipeline. If there is not enough space to hold the data for all the write pipelines, as long as the pipe is not locked by the reader. Then Linux locks the writer and copies the bytes written from the write process's address space to the shared data page. If the pipe is locked by the reader or there is not enough space to store the data, the current process sleeps in the waiting queue of the pipeline Inode, and the dispatch manager begins execution to select another process to execute. If the write process is interruptible, it will be awakened by the reader when enough space is available or the pipe is unlocked. When data is written, the VFS Inode of the pipeline is unlocked, and any reader process that sleeps on the waiting queue for this inode is awakened. The process of reading the data is similar to writing.

Linux also supports named pipes (named pipe), which is the FIFO pipeline , because it always works in first-in-and-out principles. The first data that is written will be read from the pipeline first. Unlike other pipelines, FIFO pipelines are not temporary objects, they are entities in the file system and can be created by using the Mkfifo command. The process can freely use the FIFO pipeline as long as it has the appropriate permissions. The FIFO pipeline is opened in a slightly different way. Other pipelines need to be created first (its two file data structures, Vfsinode, and shared data pages), and the FIFO pipeline already exists and needs to be opened and closed by the consumer. Before the writer process opens it, Linux must let the reader process open the FIFO pipeline first, and any reader process must write the data to it before it is read by the writer process. FIFO pipelines are used in the same way as normal pipelines, and they use the same data structures and operations.

Socket Interface (Message Queuing, semaphore, and shared memory)

Linux supports three interprocess communication mechanisms in the UNIX System V (1983) version. They are message queues, signals
Light and shared memory. These systems v IPC mechanisms use a common authorization method. The flag Nginx only through system calls
Once passed to the kernel, the process can access the resources.

Message Queuing
Message Queuing allows one or more processes to write to and read messages to it. Linux maintains a list of Msgque message queues, each of which points to a MSQID_DS structure describing the message queue. When a new message queue is created, the system allocates a MSQID_DS structure from system memory and inserts it into the array.

In addition, Linux retains information about queue modification time, such as when the last time the system was written to the queue. The msqid_ds contains two waiting queues: one for queue write processes and the other for queue read processes. Because Linux strictly restricts the number and length of messages that can be written, the message may not fit in the queue. At this point, the write process is added to the wait queue for this message queue, and the dispatch manager is called to select a new process to run. When the message is freed from this queue, the process is awakened. The process of reading from the queue is similar to this.

Lights

The simplest form of a semaphore is a memory unit that can be inspected and set (Test&set) by multiple processes. This test and setup operation is non-disruptive or an atomic operation for each process; no one can stop it once it's started. The result of the test and set operation is the current value of the Semaphore plus 1, which can be a positive or negative number. Depending on the result of this operation, the process may be able to sleep until the value of this semaphore is changed by another process. A semaphore can be used to implement a critical section (critical region): At some point the code in this area can only be executed by one process. If you have multiple collaboration processes read and write records from one data file. Sometimes you may need these file accesses to follow a strict access order. You can then use a semaphore with an initial value of 1 on the file operation code, with two semaphore operations, one for the semaphore value minus 1, and the other for 1. The first process to access the file will attempt to reduce the semaphore value by 1, and if successful, the semaphore value becomes 0. This process then starts using the data file, but if another process wants to reduce the semaphore value by 1, the semaphore value will be-1, and the operation will fail. It suspends execution until the first process completes the use of this data file. At this point the wait process will be awakened, this time it will be successful operation of the semaphore.

But the use of beacons can have a serious problem: deadlocks. A deadlock occurs when a process enters the critical section and it changes the value of the semaphore and leaves the critical section because the operation fails or is killed without changing back to the semaphore. Linux prevents this by maintaining a set of linked lists that describe the changes in the semaphore array. It does this by allowing Linux to set this semaphore to the state it was before the process operated on it. These status values are stored in the Sem_undo structure of the semid_ds and task_struct structures that use the semaphore array process.

Shared memory

Shared memory allows one or more processes to communicate through memory that appears in their virtual address space at the same time. This virtual memory page appears in each Shared Process page table. However, this page does not necessarily reside in the same location for all shared process virtual memory. As with other System V IPC objects, access to the shared memory area is controlled by the key and access permission checks. Once the memory is shared, it will no longer verify how the process is used by the object. It relies on other mechanisms, such as System V beacons, to synchronize access to shared memory.

How Linux processes communicate with each other