Inter-process communication---pipelines

Although I have seen apue this book, but still practice the truth. Although I have seen the relevant content, but just stay on the theoretical level, the problem encountered today is in Daniel's prompt to understand the reason---the pipeline communication between the processes caused the process to block.

The problem is that, using the resource manager rigger-ng to start the nginx process, the card in the Nginx syntax check one step and can not continue down, resulting in nginx cannot start. At first I and colleague toss half a day thought is Nginx configuration problem, later discovered is the process of communication out of the problem, Nginx boot process need to pass through the pipeline and another process responsible for writing the log, and another process responsible for writing the log, that is responsible for reading the pipeline process is not started. Take advantage of the time in Sunday, the original view of the process of communication between the pipeline to review the content again, make a record.

Communication between processes typically is: Anonymous pipe (pipe), well-known pipeline (FIFO), Message Queuing, semaphores, shared storage, and sockets. Pipeline is one of the oldest and widely used communication methods, generally only support half-duplex communication mode (a pipeline can only send data in one direction, but not send). While some systems now support full-duplex pipeline communication, it is generally not an assumption when used. here is a review of the communication between the anonymous pipe (pipe) and the famous pipe (Fifio).

　　One, anonymous pipe (pipe)

　　Anonymous pipes, as the name implies, is a pipe without a name. It is because this pipeline has no name, so its application is limited. This pipeline can only be used for communication between processes that have affinity, that is, parent-child processes or sibling processes. In essence, an anonymous pipe can be understood as a special file system, except that the file system differs from the file system under UNIX, which does not exist on disk, but is present in the memory of the computer (a bit similar to the/proc in the file system). Its creation function is as follows:

#include <unistd.h>

int pipe (int fd[2]);

After the pipeline was created successfully, two file descriptors fd[0] and fd[1 were returned via FD. Fd[0] is opened for reading, Fd[1] is open for writing, fd[1] output is exactly the input of fd[0].

Because it is half-duplex communication, the flow of data between the processes that communicate through the pipeline is shown in 1, of course, by closing the different file descriptors, which can also reverse the flow of data.

Figure 1 Data flow diagram for anonymous pipelines

As mentioned above, the communication of anonymous pipelines is generally applied between the processes that are related, so the creation function of the anonymous pipe is generally used with the creation function fork of the process. The following program is a parent-child process that communicates through a pipeline whose data flow direction is a child process, the parent process, so the parent process is closed and the read end, and the child process closes the write end. The procedure is as follows:

1#include <stdlib.h>2#include <stdio.h>3#include <unistd.h>4 5 intMain ()6 {7     intN;8     intfd[2];9 pid_t pid;Ten     Charline[1024x768]; One  A     if(Pipe (FD) <0) -     { -fprintf (stderr,"Cann ' t create the pipe!\n"); the exit (exit_failure); -     }     -     if(PID = fork ()) <0){ -fprintf (stderr,"Cann ' t fork process!\n"); + exit (exit_failure); -     } +     Else if(pid>0){ AClose (fd[0]); atWrite (fd[1],"Hello world\n", A); -     } -     Else{ -Close (fd[1]); -n = Read (fd[0], line,1024x768); - Write (Stdout_fileno, line, n); in     } -Exit0); to}

This is consistent with the direction of the data flow in Figure 1. First use pipe (fd[2]) to create the pipeline, and then the main process (in this program is the parent process) fork a child process, the parent-child process closes the read and write, respectively, so that the parent process can write data to the child process.

　　1. Description of the read and write rules for anonymous pipelines:

　　1.1 Read Process

• When read is a pipe that has been closed by the write end, after all the data has been read, read returns 0 to identify that the pipe has been read. Technically, there is no end to the file if there is a process at the end of the pipeline.
• If you read a process that still exists on the write side, if the number of bytes read at one time is greater than the maximum number of bytes the pipeline can hold (PIPE_BUF indicates the maximum number of bytes the pipeline can hold, which can be obtained through the pathconf and fpathconf functions), the number of existing bytes in the pipeline is returned If the requested amount of data is not greater than pipe_buf, the number of bytes requested to read (less than the number of bytes requested) or the number of existing bytes in the pipeline (the number of existing bytes in the pipeline is less than the number of bytes requested).
• If the write-side exists, but there is no data in the pipeline, the read end is blocked.

　　1.2 Write process

　　When writing data to a pipeline, PIPE_BUF specifies the size of the pipe buffer in the kernel. If write is called on the pipe and the number of bytes written is less than or equal to PIPE_BUF, this operation does not cross the write operation of the other process to the same pipe. However, if more than one process is writing a pipeline to the pipeline and the number of bytes written is greater than PIPE_BUF, the abbreviated data will intersect with the other processes. if the pipeline is full and no read process reads the data in the pipeline, the write operation will be blocked.

　　Another problem to be aware of is that writing data to a pipeline is meaningful only if the read side exists. If the read side does not exist (there is no or has been closed), then the signal sigpipe, the application can process the signal or ignore (the default action is to make the application terminate).

　　Second, named pipe (FIFO)

To overcome the disadvantage that anonymous pipelines can only communicate between affinity processes, a named pipe is proposed. Named pipes are different from anonymous pipes in that you need to provide a pathname parameter when creating a named pipe, which is already in the file system in the form of a FIFO. This way, even processes that are not related to the process that created the FIFO can communicate with each other through the FIFO as long as the path can be accessed. The function to create the FIFO is as follows:

#include <sys/stat.h>

int Mkfifo (const char *path,mode_t mode);

If path is just an ordinary pathname, the path is the pathname after the FIFO is created, the path name exists in the file system, but the contents of the pipeline still exist in memory, the second parameter mode_t with the normal file Open function open (const char* path, int Oflag,.../*mode_t mode*/); mode_t is consistent. Here we will highlight the O_nonblock option in the mode_t parameter. If the pathname path already exists, the function returns a eexist error, so the first check is to return the eexist error after creating the FIFO with the FIFO creation function, and if the error is returned, the Open function of the FIFO can be called directly, and if other errors are returned, It proves that the creation FIFO is unsuccessful.

　　Rules for Open calls

After we have successfully created the FIFO to open the file with the open function, there are two scenarios depending on whether the blocking flag is set:

• No O_nonblock specified: The read-only open call waits until some other process has opened the FIFO for writing, and the same write-only open waits until a process has opened it for reading If the read-only (write) open opens the FIFO before opening the process for write-only (read) open, the open immediately returns the flag for success. That is, if O_nonblock is not specified, either the read end or the write end will block until the other process opens the change FIFO for write or read.
• O_nonblock: Read-only open returns the successful flag immediately, but if no process opens a FIFO for reading, the write-only open call fails, returns 1 and resets the error to Enxio.

The above is the correspondence between the various situations that open this FIFO and the O_nonblock. The following is a detailed explanation of the FIFO write process and the read process.

　　Rules for the reading and writing of destined pipelines

1. Read process

If a process opens the FIFO in a blocking manner in order to read data from the FIFO (without setting o_nonblock), the kernel is said to have a blocking flag set for the read operation of the change process.

• If a process has already opened a FIFO for write and there is no data in the named pipe at this time, the read process will remain blocked, and if O_nonblock is set, the read will immediately return-1, and the error will be reset to Eagin;
• If there is no process to write and open the FIFO, then no set o_nonblock read operation will be blocked until a process for the write and open the change FIFO;
• If the write process is closed, the read process reads the data while the pipeline is in, and if there is no data in the pipeline, the read process returns 0;

　　2. Write process

If a process opens the FIFO in a blocking manner in order to write data to the FIFO (without setting o_nonblock), the kernel is said to have a blocking flag set for the write operation of the change process.

• The O_nonblock is not set when the call Open is opened for writing and is written in block mode. If the number of bytes written is not greater than pipe_buf, the atomicity of the write is guaranteed. If the free space of the pipeline is less than the number of bytes to be written, the write process is blocked until the space in the buffer holds the number of bytes to be written, and all data is written once, and if the number of bytes written is greater than Pipe_buf, the write atomicity is not guaranteed. As long as the FIFO buffer has free space, the write process writes the data to the buffer, and the write operation returns after all the data has been written;
• If O_nonblock is set when the call Open is opened for write, it is written in a non-blocking manner. If the number of bytes written is greater than pipe_buf, the atomicity of the write is not guaranteed, and the write is returned after all the FIFO buffers have been written, and if the number of bytes written is less than Pipe_buf, the write atomicity will be guaranteed. If the free space in the FIFO is greater than the number of bytes to write, the return succeeds after one-time write, otherwise the Eagin error is returned, and the reminder is later written.

only if the read end is present, the write end makes sense, if the read end does not exist, then writes the data to the FIFO, then the kernel sends the SIGPIPE signal to the write process (the default terminating process). This is also the cause of the problems encountered this time.

Summarize:

　　Theoretical knowledge can not be seen, but after encountering problems must be searched or consulted others, even if the corresponding knowledge points.

　　

Inter-process communication---pipelines