Linux core-6. Inter-process communication mechanism

Article title: Linux core-6. Inter-process communication mechanism. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Original: David A Rusling
Translation: Banyan & fifa
　　
Chapter 5 Inter-process communication mechanism
　　
Processes communicate with each other under the coordination of the core. Linux supports a large number of inter-process communication (IPC) mechanisms. In addition to signals and pipelines, Linux also supports the IPC mechanism in Unix System V.
5.1 Signal
Signals are the oldest way of inter-process communication in Unix systems. They are used to send asynchronous event signals to one or more processes. Signals can be generated from keyboard interruptions. In addition, the process may also generate signals in a system error environment, such as illegal access to the virtual memory by the process. The signal is also used by shell programs to send task control commands to its sub-processes.
There is a set of signal types defined in detail in the system. these signals can be generated by other processes with proper permissions in the core or system. Use the kill command (kill-l) to list all defined signals in the system. The running result on my system (Intel System) is as follows:
　　
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGIOT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR
　　
When I run this command in Alpha AXP, different numbers of signals are obtained. Except for two signals, the process can ignore the vast majority of these signals. One is the SIGSTOP signal that causes the process to terminate and the other is the SIGKILL signal that causes the process to exit. For other signals, the process can choose the specific method to process them. A process can block a signal. if the signal is not blocked, you can choose between processing the signal and transferring it to the core. If the core processes the signal, it uses the default processing method corresponding to the signal. For example, when a process receives SIGFPE (floating point number exception), the core default operation causes the core dump and process exit. The signal has no inherent relative priority. If two signals are generated for a process at the same time, they may arrive at the process and process it in any order. At the same time, Linux does not support processing multiple signals of the same type. That is, the process cannot distinguish whether it receives one or 42 SIGCONT signals.
　　
Linux uses information stored in the task_struct process to implement signals. The number of signals is limited by the processor's word length. A 32-bit processor can have up to 32 signals, while a 64-bit processor such as Alpha AXP can have up to 64 signals. Currently, unprocessed signals are stored in the signal domain and are shielded with blocked signals stored in blocked. All signals except SIGSTOP and SIGKILL can be blocked. When a blocking signal is generated, the signal can remain in the pending status until it is blocked and released. In Linux, information about each process processing every possible signal is stored in the sigaction array in task_struct. The information includes the process address corresponding to the signal to be processed by the process, or indicates whether to ignore the signal or to process its mark by the core. By calling the system, the process can modify the default signal processing process, which changes the sigaction of a signal and blocks the shielding code.
　　
Not every process in the system can send signals to all other processes: only the core and super users have this permission. Normal processes can only send signals to processes with the same uid and gid or in the same process Group. Signals are generated by setting a position in the signal field in the task_struct structure. If the process does not have a blocking signal and is in an interrupted wait state, you can change it to Running. If you confirm that the process is still in the Running queue, you can wake it up by the signal. In this way, the scheduling manager selects the system to run the task next time it is scheduled. If the process requires a default signal processing process, Linux can optimize the processing of this signal. For example, for SIGWINCH (focus change in X window) signals, the default processing process is nothing.
　　
The signal is not sent to the process immediately after it is generated, but is sent to the process only after the process runs again. Every time a process exits from a system call, it checks the signal and blocked domains to see if there are non-blocking signals that can be sent immediately. This seems unreliable, but every process in the system is constantly calling the system, such as outputting characters to the terminal. Of course, the process can choose to wait for the signal. at this time, the process will remain in the interrupted state until the signal appears. The processing code for the current non-blocking signal is placed in the sigaction structure.
　　
If the signal processing process is set to the default value, the core will handle it. The default processing process of the SIGSTOP signal is to change the status of the current process to Stopped and run the scheduling manager to select a new process to continue running. The default processing process of SIGFPE is to cause the core dump and exit the process. Of course, a process can define its own signal processing process. Once the signal is generated, this process will be called. Its address is stored in the sigaction structure. The core must call the process's signal processing routine. how to do it depends on the processor type, but all CPUs must handle this problem: if the signal is generated, the current process is running in the core mode and will immediately return the process that calls the core or system routine. The process is in the user mode. To solve this problem, you need to manipulate the stack and register of the process. The program counter of a process is set to the address of its signal processing process, and the parameters are transmitted to the processing routine by calling the framework or register. When the process continues to run, the signal processing routine is like a common function call.
Linux is POSIX compatible, so when a specific signal processing routine is called, the process can set which signal can be blocked. This means that blocked shielding codes can be changed during process signal processing. When the signal processing routine ends, the blocked shielding code must be set to the original value. Therefore, a process call is added to Linux to refresh the original blocked shielding code in the call stack of the sent Signal Process. For several signal processing processes at the same time point, Linux uses the stack method to optimize its use. when a processing process exits, the next processing process must wait until the completion of the sorting routine.
　　
5.2 pipelines
Generally, Linux shell programs allow redirection. For example
　　
$ Ls | pr | lpr
　　
In this pipeline application, the output of the current ls directory is sent to the pr program as a standard input, and the output of pr is sent to the lpr program as a standard input. A pipe is a unidirectional byte stream that connects the standard output of a process to the standard input of another process. However, processes using pipelines do not realize the existence of redirection, and their execution results are not different. The shell program is responsible for creating temporary pipelines between processes.
. 1 MPs queue
　　
In Linux, pipelines are implemented by pointing to two file data structures of the same temporary VFS inode. this VFS inode points to a physical page in the memory .. 1. each file data structure points to different file operation routine vectors. one is to write data to the pipeline, and the other is to read data from the pipeline.
　　
In this way, the differences between read/write pipelines and system calls when reading and writing common files are hidden. When the write process writes data to the MPs queue, the bytes are copied to the shared data page. when the read process reads data from the MPs queue, the bytes are copied from the shared data page. Linux must synchronize access to the MPs queue. It must ensure that the reader and writer perform the execution in a specific step, so synchronization mechanisms such as Lock, waiting queue, and signal are required.
　　
When a writer wants to write data to an MTS queue, the writer uses the standard writing function. Indicates the description of opening a file and opening a pipeline to index the file data structure set of the process. The Linux system calls the write process directed by the data structure of the pipeline file. This write process manages write requests by saving the information in the VFS inode that represents the MPs queue.
　　
If you do not have enough space to accommodate all the data written into the pipeline, as long as the pipeline is not locked by the reader. Linux locks the writer and copies the bytes written from the write process address space to the shared data page. If the pipeline is locked by the reader or there is not enough space to store data, the current process will sleep in the queue waiting for inode in the pipeline, and the scheduling manager starts to execute to select other processes for execution. If the write process is interrupted, the reader will wake up when there is enough space or the pipeline is unlocked. When data is written, the VFS inode of the MPs queue is unlocked, and any reader processes sleeping in the queue waiting for the inode will be awakened.
Reading data from an MPs queue is similar to writing data.
　　
The process allows non-blocking reads (depending on the way they open files or pipelines). if there is no readable data or the pipeline is locked, an error message is returned indicating that the process can continue. Blocking causes the reader process to sleep in the queue waiting for inode in the pipeline until the writer process ends. When the use of the MPs queue ends, the inode and the data sharing page of the MPs queue are abandoned at the same time.
　　
Linux also supports named pipelines (named pipe), that is, the FIFO pipeline, because it always works in accordance with the principle of first-in-first-out. The first data to be written is first read from the pipeline. Unlike other pipelines, FIFO pipelines are not temporary objects. they are entities in the file system and can be created using the mkfifo command. As long as the process has the appropriate permissions, it can freely use the FIFO pipeline. The method for opening a FIFO pipeline is slightly different. Other pipelines need to be created first (the two file data structures, VFS inode and shared data pages), and the FIFO pipeline already exists, which only needs to be opened and closed by the user. Before the writer process opens it, the reader process must first open the FIFO pipeline in Linux; before any reader process reads it, the writer process must write data to it. The use of FIFO pipelines is basically the same as that of common pipelines, and they use the same data structure and operation.
　　
5.3 sets of interfaces
　　
5.3.1 System v ipc mechanism
Linux supports three inter-process communication mechanisms in the Unix System V (1983. They are message queues, signal lights, and shared memory. These system v ipc mechanisms use a common authorization method. The process can access these resources only after the token is passed to the core through a system call. These system v ipc objects use access control methods similar to those of file systems. The object reference identifier is used as an index in the resource table. This index value must be processed before it can be obtained.
The Linux data structure of all system v ipc objects in the system contains an ipc_perm structure, which contains the process owner, creator, and group identifier. In addition, the access mode and IPC object key for this object (owner, group, and others) are also provided. This key value is used to locate the reference identifier of the System v ipc object. There are two groups of such key values: public and private. If this key is public, any process in the system that accepts the permission check can find the reference identifier of the System v ipc object. The system v ipc object cannot be referenced by a single key value, but can only be referenced by a reference identifier.
5.3.2 Message Queue
A message queue allows one or more processes to write and read messages to it. Linux maintains a msgq