Source | TLPI System Programming Notes

Compiled & formatted | Embedded Application Research Institute

Overview

The most common use of pipes is in the shell, for example:

$ ls | wc -l

To execute the above command, the shell creates two processes to execute ls and wc (achieved through fork() and exec()), as shown below:

Exploring the Many Uses of Linux Pipes

From the above diagram, we can see that a pipe can be viewed as a set of water pipes, allowing data to flow from one process to another, which is also the origin of the name “pipe”.

As shown in the diagram, two processes are connected to the pipe, where the writing process ls connects its standard output (file descriptor 1) to the writing end of the pipe, while the reading process wc connects its standard input (file descriptor 0) to the reading end of the pipe. In fact, these two processes are unaware of the existence of the pipe; they simply read and write data from standard file descriptors. The shell must handle the related work.

A pipe is a byte stream

A pipe is a byte stream, meaning that there is no concept of messages or message boundaries when using a pipe:

The process reading data from the pipe can read any size of data block, regardless of the size of the data block written by the writing process.
The data passed through the pipe is sequential; the order of bytes read from the pipe is exactly the same as the order in which they were written to the pipe. The lseek() function cannot be used for random access to data in the pipe.

If there is a need to implement the concept of discrete messages in a pipe, this must be done within the application. While this is feasible, it is better to use other IPC mechanisms, such as message queues and datagram sockets, if such a requirement arises.

Reading data from a pipe

Attempting to read data from an empty pipe will block until at least one byte is written to the pipe.

If the writing end of the pipe is closed, the process reading data from the pipe will see an end-of-file (EOF) after reading all remaining data in the pipe (i.e., read() returns 0).

Pipes are unidirectional

The direction of data transfer in a pipe is unidirectional. One end of the pipe is for writing, and the other end is for reading.

In some other UNIX implementations, particularly those evolved from System V Release 4, pipes are bidirectional (known as stream pipes). Bidirectional pipes are not specified in any UNIX standard, so even in implementations that provide bidirectional pipes, it is best to avoid relying on this semantics. As an alternative, UNIX domain stream socket pairs (created via the socketpair() system call) provide a standard bidirectional communication mechanism, and their semantics are equivalent to stream pipes.

Operations that ensure writing does not exceed PIPE_BUF bytes are atomic

If multiple processes write to the same pipe, it can be ensured that the data written will not intermingle if the amount of data they write at any one time does not exceed PIPE_BUF bytes.

SUSv3 requires that PIPE_BUF be at least _POSIX_PIPE_BUF(512). An implementation should define PIPE_BUF (in <limits.h>) and/or allow calling fpathconf(fd,_PC_PIPE_BUF) to return the actual limit for atomic write operations.

Different UNIX implementations have different PIPE_BUF values; for example, in FreeBSD 6.0, its value is 512 bytes, in Tru64 5.1, it is 4096 bytes, in Solaris 8, it is 5120 bytes, and in Linux, the value of PIPE_BUF is 4096.

When the size of the data block written to the pipe exceeds PIPE_BUF bytes, the kernel may split the data into several smaller fragments for transmission, appending subsequent data when the reader consumes data from the pipe (write() calls will block until all data is written to the pipe).
When only one process writes data to the pipe (the usual case), the value of PIPE_BUF does not matter.
However, if there are multiple writing processes, large data block writes may be broken into segments of arbitrary size (possibly smaller than PIPE_BUF bytes), and there may be instances of data interleaving with data written by other processes.

The PIPE_BUF limit only takes effect when data is being transferred to the pipe. When the data reaches PIPE_BUF bytes, write() will block as necessary until there is enough available space in the pipe to atomically complete this operation. If the data being written exceeds PIPE_BUF bytes, then write() will transfer as much data as possible to fill the pipe and then block until some reading process removes data from the pipe. If such a blocking write() is interrupted by a signal handler, this call will be unblocked and return the number of bytes successfully transferred to the pipe, which will be less than the requested number of bytes (known as a partial write).

The capacity of a pipe is limited

A pipe is essentially a buffer maintained in kernel memory, and this buffer has a limited storage capacity. Once the pipe is filled, subsequent write operations to the pipe will block until the reader removes some data from the pipe.

SUSv3 does not specify the storage capacity of pipes. In Linux kernels prior to 2.6.11, the storage capacity of pipes was consistent with the size of the system page (e.g., 4096 bytes on x86-32), while from Linux 2.6.11 onwards, the storage capacity of pipes is 65,536 bytes. The storage capacity of pipes in other UNIX implementations may vary.

Generally, an application does not need to know the actual storage capacity of a pipe. If it is necessary to prevent the writing process from blocking, the process reading data from the pipe should be designed to read data from the pipe as quickly as possible.

Creating and using pipes

#include <unistd.h>

int pipe(int fd[2]);

pipe() creates a new pipe.
A successful call returns two open file descriptors in the array fd, one representing the reading end of the pipe fd[0], and the other representing the writing end of the pipe fd[1]

When calling the pipe() function, a buffer is first allocated in the kernel for communication, which has a read end and a write end, and then two file descriptors are passed to the user process through the fd parameter, where fd[0] points to the read end of the pipe, and fd[1] points to the write end of the pipe.

Do not write data using fd[0] or read data using fd[1]; such behavior is undefined, but on some systems, it may return -1 indicating a failure. Data can only be read from fd[0] and written to fd[1], not the other way around.

As with all file descriptors, the read() and write() system calls can be used to perform IO on the pipe. Once data is written to the writing end of the pipe, it can be immediately read from the reading end of the pipe. The read() call on the pipe will read the smaller of the requested number of bytes and the number of bytes currently in the pipe. When the pipe is empty, the read operation blocks.

It is also possible to use stdio functions (printf(), scanf(), etc.) on the pipe, but first, you need to use fdopen() to obtain a file stream corresponding to one of the descriptors in filedes. However, when doing this, you need to address the stdio buffering issue.

Pipes can be used for inter-process communication:

Exploring the Many Uses of Linux Pipes

Pipes can be used for communication between related processes (child processes inherit copies of file descriptors from the parent process):

Exploring the Many Uses of Linux Pipes

It is not advisable to use a single pipe as full-duplex, or to not close the corresponding read end/write end when used as half-duplex, as this can easily lead to deadlocks: if two processes attempt to read data from the pipe simultaneously, it cannot be determined which process will read successfully first, resulting in competition for data between the two processes. To prevent such competition, some synchronization mechanism is required. At this point, deadlock issues must be considered, as if both processes attempt to read from an empty pipe or write to a full pipe, deadlock may occur.

If we want a bidirectional data flow, we can create two pipes, one for each direction.

Pipes allow communication between related processes

In fact, pipes can be used for communication between any two or more related processes, as long as a pipe is created by a common ancestor process before the series of fork() calls to create child processes.

Closing unused pipe file descriptors

Closing unused pipe file descriptors is not only to ensure that processes do not exhaust their file descriptor limits.

The process reading data from the pipe will close its writing descriptor, so that when other processes finish output and close their writing descriptors, the reader will see the end of the file. Conversely, if the reading process does not close the writing end of the pipe, then after other processes close the writing descriptor, even if the reader has read all the data in the pipe, it will not see the end of the file. This is because the kernel knows that at least one writing descriptor of the pipe is still open, causing read() to block.

When a process attempts to write data to a pipe but no process has an open reading descriptor for that pipe, the kernel sends a SIGPIPE signal to the writing process, which by default will kill the process, but the process can choose to ignore it or set a signal handler, so that write() will fail with an EPIPE error. Receiving a SIGPIPE signal and getting an EPIPE error is significant for identifying the state of the pipe, which is why it is necessary to close unused reading descriptors of the pipe. If the writing process does not close the reading end of the pipe, then even after other processes have closed the reading end of the pipe, the writing process can still write data to the pipe, eventually filling the entire pipe, and subsequent write requests will block forever.

Using pipes to connect filters

Once a pipe is created, the file descriptors allocated for the two ends of the pipe are the two smallest available descriptors. Since processes typically already use descriptors 0, 1, and 2, some larger descriptor values will be allocated for the pipe. If you need to use a pipe to connect two filters (i.e., reading from stdin and writing to stdout), so that the standard output of one program is redirected to the pipe, you need to use the file descriptor duplication technique.

int pfd[2];
pipe(pfd);

close(STDOUT_FILENO);
dup2(pfd[1], STDOUT_FILENO);

The result of these calls is that the standard output of the process is bound to the writing end of the pipe, and a corresponding set of calls can be used to bind the standard input of the process to the reading end of the pipe.

Communicating with shell commands through pipes: `popen()`

#include <stdio.h>

FILE *popen (const char *command, const char *mode);

pipe() and close() are the lowest-level system calls, and their further encapsulation is provided by popen() and pclose()
popen() creates a pipe, then creates a child process to execute the shell, which in turn creates a child process to execute the command string.
mode parameter is a string:

It determines whether the calling process reads data from the pipe (mode is r) or writes data to the pipe (mode is w).
Since pipes are unidirectional, bidirectional communication cannot be performed in the executed command.
mode value determines whether the standard output of the executed command is connected to the writing end of the pipe or its standard input is connected to the reading end of the pipe.

Exploring the Many Uses of Linux Pipes

popen() returns a file stream pointer for use with stdio library functions upon success. When an error occurs, popen() returns NULL and sets errno to indicate the reason for the error.
After the popen() call, the calling process uses the pipe to read the output of the command or sends input to it. As with pipes created using pipe(), when reading data from the pipe, the calling process will see the end of the file after the command closes the writing end of the pipe; when writing data to the pipe, if the command has already closed the reading end of the pipe, the calling process will receive a SIGPIPE signal and get an EPIPE error.

#include <stdio.h>

int pclose ( FILE * stream);

Once IO is finished, the pclose() function can be used to close the pipe and wait for the child process’s shell to terminate (the fclose() function should not be used, as it will not wait for the child process).
pclose() returns the termination status of the shell in the child process upon success (i.e., the termination status of the last command executed by the shell, unless the shell was killed by a signal).
Like system(), if the shell cannot be executed, pclose() will return a value as if the shell terminated by calling _exit(127).
If other errors occur, pclose() returns -1. One possible error is the inability to obtain the termination status.

When waiting to obtain the status of the shell in the child process, SUSv3 requires that pclose() behaves like system(), meaning that if the internal waitpid() call is interrupted by a signal handler, that call is automatically restarted.

Like system(), popen() should never be used in privileged processes.

popen advantages and disadvantages:

Advantages: In Linux, all parameter expansions are performed by the shell. Therefore, before starting the command command, the program first starts the shell to analyze the command string, allowing the use of various shell expansions (such as wildcards), enabling very complex shell commands to be executed through the popen() call.
Disadvantages: For each popen() call, not only is the requested program started, but a shell is also started. Thus, each popen() will start two processes. From an efficiency and resource perspective, the call to popen() is slower than the normal method.

pipe() VS popen()

pipe() is a low-level call, while popen() is a high-level function.
pipe() simply creates a pipe, while popen() creates a pipe and forks a child process at the same time.
popen() requires a shell to interpret the requested command when passing data between two processes; pipe() does not require starting a shell to interpret the requested command, while providing more control over reading and writing data (popen() must be a shell command, while pipe() has no such requirement).
popen() works with file streams (FILE), while pipe() works with file descriptors, so after using pipe(), data must be read and sent using the lower-level read() and write() calls.

Pipes and stdio buffering

Since the file stream pointer returned by the popen() call does not reference a terminal, the stdio library applies block buffering to such streams. This means that when calling popen() with a mode value of w, the data sent to the child process at the other end of the pipe will only be sent when the stdio buffer is full or when the pipe is closed using pclose(). In many cases, this behavior is not an issue. However, if it is necessary to ensure that the child process can immediately receive data from the pipe, it is necessary to periodically call fflush() or use setbuf(fp, NULL) to disable stdio buffering. This technique can also be used when creating a pipe with the pipe() system call and then using fdopen() to obtain a stdio stream corresponding to the writing end of the pipe.

If the process calling popen() is reading data from the pipe (i.e., mode is r), things are not so simple. In this case, if the child process is using the stdio library, then—unless it explicitly calls fflush() or setbuf()—its output will only be available to the calling process after the child process fills the stdio buffer or calls fclose(). (If reading data from a pipe created with pipe() and the process writing to the other end is also using the stdio library, the same rules apply.) If this is an issue, the measures that can be taken are quite limited unless the source code of the program running in the child process can be modified to include calls to setbuf() or fflush().

If modifying the source code is not possible, a pseudo-terminal can be used to replace the pipe. A pseudo-terminal is an IPC channel that behaves like a terminal to processes. As a result, the stdio library will output data from the buffer line by line.

Named pipes (FIFO)

While the above pipes achieve inter-process communication, they have certain limitations:

Anonymous pipes can only communicate between related processes.
They can only allow one process to write and another to read; if both need to occur simultaneously, a new pipe must be opened.

To enable communication between any two processes, named pipes (FIFO) were introduced:

Difference between FIFO and pipes: FIFO has a name in the file system and can be opened like a regular file, allowing communication between any two processes. Anonymous pipes are not visible to the file system and are limited to communication between parent and child processes.
Once a FIFO is opened, IO system calls such as read(), write(), and close() can be used on it just like with pipes and other files. Like pipes, FIFO also has a writing end and a reading end, and always follows the first-in-first-out principle, meaning the first data in will be the first to be read.
Like pipes, when all references to a FIFO are closed, all unread data will be discarded.
The mkfifo command can be used in the shell to create a FIFO:

mkfifo [-m mode] pathname

pathname is the name of the created FIFO, and the -m option specifies permissions mode, which works like the chmod command.
fstat() and stat() functions will return S_IFIFO in the st_mode field of the stat structure; when listing files with ls -l, the type of FIFO files in the first column is p, and ls -F will append a pipe symbol to the FIFO pathname.

#include <sys/types.h>
#include <sys/stat.h>

int mkfifo(const char *pathname, mode_t mode);

mode parameter specifies the permissions for the new FIFO, which will be masked by the process’s umask value.
Once a FIFO is created, any process can open it as long as it passes the regular file permission checks.
The only sensible practice when using FIFO is to set up a reading process and a writing process at both ends. This way, by default, opening a FIFO for reading (open() O_RDONLY flag) will block until another process opens the FIFO for writing (open() O_WRONLY flag). Correspondingly, opening a FIFO for writing will block until another process opens the FIFO for reading. In other words, opening a FIFO synchronizes the reading and writing processes. If one end of a FIFO is already open (possibly because a pair of processes have opened both ends of the FIFO), then the open() call will succeed immediately.

In most Unix implementations (including Linux), when opening a FIFO, you can bypass the blocking behavior by specifying the O_RDWR flag. This way, the open() call will return immediately, but you cannot read and write data using the returned file descriptor on the FIFO. This practice breaks the IO model of FIFO, and SUSv3 explicitly states that the result of opening a FIFO with the O_RDWR flag is undefined, so for portability reasons, developers should not use this technique. For those needing to avoid blocking when opening a FIFO, the open() call with the O_NONBLOCK flag provides a standardized way to accomplish this:

open(const char *path, O_RDONLY | O_NONBLOCK);
open(const char *path, O_WRONLY | O_NONBLOCK);

Another reason to avoid using the O_RDWR flag when opening a FIFO is that after calling it that way, the calling process will never see the end of the file when reading data from the returned file descriptor, as there will always be at least one file descriptor open waiting for data to be written to the FIFO, which is the descriptor from which the process is reading data.

Using FIFO and `tee` to create dual pipelines

One feature of shell pipelines is that they are linear; each process in the pipeline can read the data produced by the previous process and send it to the next process. Using FIFO allows creating subprocesses in the pipeline, so that in addition to sending the output of one process to the next process in the pipeline, the output can also be copied and sent to another process. To accomplish this task, the tee command is needed, which reads data from standard input and copies it, outputting one copy to standard output and the other to a file specified by command line arguments.

mkfifo myfifo
wc -l < myfifo &&
ls -l | tee myfifo | sort -k5n

Exploring the Many Uses of Linux Pipes

Non-blocking IO

When a process opens one end of a FIFO, if the other end of the FIFO has not yet been opened, that process will be blocked. However, sometimes blocking is not the desired behavior, and this can be achieved by specifying the O_NONBLOCK flag when calling open().

If the other end of the FIFO is already open, the O_NONBLOCK flag will have no effect on the open() call, which will succeed immediately as if the other end of the FIFO had been opened. The O_NONBLOCK flag will only take effect when the other end of the FIFO has not been opened, and the specific effects depend on whether the FIFO is being opened for reading or writing:

If the FIFO is opened for reading and the writing end is currently open, the open() call will succeed immediately (as if the other end of the FIFO had been opened).
If the FIFO is opened for writing and the other end has not been opened for reading, the open() call will fail and set errno to ENXIO

The different effects of the O_NONBLOCK flag when opening a FIFO for reading and writing are for a reason. It is not a problem to open a FIFO for reading when there is no writer on the other end, as any attempts to read data from the FIFO will not return any data. However, attempting to write to a FIFO with no reader will result in the generation of a SIGPIPE signal and the write() call will return an EPIPE error.

The semantics of calling open() on a FIFO can be summarized as follows:

Exploring the Many Uses of Linux Pipes

When opening a FIFO, using the O_NOBLOCK flag serves two purposes:

It allows a single process to open both ends of a FIFO, where the process first opens the FIFO for reading by specifying the O_NOBLOCK flag, and then opens the FIFO for writing.
It prevents deadlocks from occurring between processes that open both ends of two FIFOs.

For example, the following situation will lead to a deadlock:

Exploring the Many Uses of Linux Pipes

Non-blocking `read()` and `write()`

O_NONBLOCK flag not only affects the semantics of the open() call, but also affects—because this flag is still set in the open file description—the semantics of subsequent read() and write() calls.

Sometimes there is a need to modify the state of the O_NONBLOCK flag for an already opened FIFO (or another type of file), and specific scenarios where this need arises include:

Using O_NONBLOCK to open a FIFO but needing subsequent read() and write() to operate in blocking mode.
Need to enable non-blocking mode for a file descriptor returned from pipe(). More generally, there may be a need to change the non-blocking state of any file descriptor obtained from other calls, such as one of the three standard descriptors automatically opened by the shell for each new program run or a file descriptor returned from socket().
For some special application requirements, there may be a need to toggle the state of the O_NONBLOCK setting on and off.

When encountering the above needs, the fcntl() function can be used to enable or disable the O_NONBLOCK state flag for an open file. The following code (ignoring error checks) can enable this flag:

int flags;

flags = fcntl(fd, F_GETFL);
flags |= O_NONBLOCK;
fcntl(fd, F_SETFL, flags);

The following code can disable this flag:

flags = fcntl(fd, F_GETFL);
flags &= ~O_NONBLOCK;
fcntl(fd, F_SETFL, flags);

Semantics of `read()` and `write()` in pipes and FIFOs

The read() operation on a FIFO:

Exploring the Many Uses of Linux Pipes

There is only a difference between blocking and non-blocking reads when there is no data and the writing end is not open. In this case, a normal read() will block, while a non-blocking read() will fail and return EAGAIN error.

When the O_NONBLOCK flag and the PIPE_BUF limit work together, the effects of the O_NONBLOCK flag on writing data to pipes or FIFOs become complex.

The write() operation on a FIFO:

Exploring the Many Uses of Linux Pipes

When data cannot be transmitted immediately, the O_NONBLOCK flag will cause a write() on a pipe or FIFO to fail (the error is EAGAIN). This means that after writing PIPE_BUF bytes, if there is not enough space in the pipe or FIFO, then write() will fail because the kernel cannot complete this operation immediately and cannot perform a partial write, otherwise it would violate the atomicity requirement for write operations not exceeding PIPE_BUF bytes.
When the amount of data written exceeds PIPE_BUF bytes, that write operation does not need to be atomic. Therefore, write() will transfer as many bytes as possible (partial write) to fill the pipe or FIFO. In this case, the value returned from write() is the actual number of bytes transferred, and the caller must then retry to write the remaining bytes. However, if the pipe or FIFO is already full, causing even a single byte to be unable to be transmitted, then write() will fail and return EAGAIN error.

Copyright belongs to the original author or platform, for learning reference and academic research only. If there is any infringement, please contact for deletion. Thank you.

The author has collected some embedded learning materials; reply with 【1024】 in the public account to find the download link!

Recommended good articles, click the blue text to jump
☞ Collection | Comprehensive Guide to Linux Application Programming
☞ Collection | Learn Some Networking Knowledge
☞ Collection | Handwritten C Language
☞ Collection | Handwritten C++ Language
☞ Collection | Experience Sharing
☞ Collection | From Microcontrollers to Linux
☞ Collection | Electric Power Control Technology
☞ Collection | Essential Mathematics for Embedded Systems
☞ Collection | MCU Advanced Collection
☞ Collection | Embedded C Language Advanced Collection

Exploring the Many Uses of Linux Pipes

Overview

A pipe is a byte stream

Reading data from a pipe

Pipes are unidirectional

Operations that ensure writing does not exceed PIPE_BUF bytes are atomic

The capacity of a pipe is limited

Creating and using pipes

Pipes allow communication between related processes

Closing unused pipe file descriptors

Using pipes to connect filters

Communicating with shell commands through pipes: `<span>popen()</span>`

Pipes and stdio buffering

Named pipes (FIFO)

Using FIFO and `<span>tee</span>` to create dual pipelines

Non-blocking IO

Non-blocking `<span>read()</span>` and `<span>write()</span>`

Semantics of `<span>read()</span>` and `<span>write()</span>` in pipes and FIFOs

Leave a Comment Cancel reply

Overview

A pipe is a byte stream

Reading data from a pipe

Pipes are unidirectional

Operations that ensure writing does not exceed PIPE_BUF bytes are atomic

The capacity of a pipe is limited

Creating and using pipes

Pipes allow communication between related processes

Closing unused pipe file descriptors

Using pipes to connect filters

Communicating with shell commands through pipes: <span>popen()</span>

Pipes and stdio buffering

Named pipes (FIFO)

Using FIFO and <span>tee</span> to create dual pipelines

Non-blocking IO

Non-blocking <span>read()</span> and <span>write()</span>

Semantics of <span>read()</span> and <span>write()</span> in pipes and FIFOs

Related posts

Leave a Comment Cancel reply

Communicating with shell commands through pipes: `<span>popen()</span>`

Using FIFO and `<span>tee</span>` to create dual pipelines

Non-blocking `<span>read()</span>` and `<span>write()</span>`

Semantics of `<span>read()</span>` and `<span>write()</span>` in pipes and FIFOs