1 .\" Copyright (C) 2005 Michael Kerrisk <mtk.manpages@gmail.com>
3 .\" %%%LICENSE_START(VERBATIM)
4 .\" Permission is granted to make and distribute verbatim copies of this
5 .\" manual provided the copyright notice and this permission notice are
6 .\" preserved on all copies.
8 .\" Permission is granted to copy and distribute modified versions of this
9 .\" manual under the conditions for verbatim copying, provided that the
10 .\" entire resulting derived work is distributed under the terms of a
11 .\" permission notice identical to this one.
13 .\" Since the Linux kernel and libraries are constantly changing, this
14 .\" manual page may be incorrect or out-of-date. The author(s) assume no
15 .\" responsibility for errors or omissions, or for damages resulting from
16 .\" the use of the information contained herein. The author(s) may not
17 .\" have taken the same level of care in the production of this manual,
18 .\" which is licensed free of charge, as they might when working
21 .\" Formatted or processed versions of this manual, if unaccompanied by
22 .\" the source, must acknowledge the copyright and authors of this work.
25 .TH PIPE 7 2005-12-08 "Linux" "Linux Programmer's Manual"
27 pipe \- overview of pipes and FIFOs
29 Pipes and FIFOs (also known as named pipes)
30 provide a unidirectional interprocess communication channel.
35 Data written to the write end of a pipe can be read
36 from the read end of the pipe.
38 A pipe is created using
40 which creates a new pipe and returns two file descriptors,
41 one referring to the read end of the pipe,
42 the other referring to the write end.
43 Pipes can be used to create a communication channel between related
48 A FIFO (short for First In First Out) has a name within the file
53 Any process may open a FIFO, assuming the file permissions allow it.
54 The read end is opened using the
56 flag; the write end is opened using the
63 although FIFOs have a pathname in the file system,
64 I/O on FIFOs does not involve operations on the underlying device
66 .SS I/O on pipes and FIFOs
67 The only difference between pipes and FIFOs is the manner in which
68 they are created and opened.
69 Once these tasks have been accomplished,
70 I/O on pipes and FIFOs has exactly the same semantics.
72 If a process attempts to read from an empty pipe, then
74 will block until data is available.
75 If a process attempts to write to a full pipe (see below), then
77 blocks until sufficient data has been read from the pipe
78 to allow the write to complete.
79 Nonblocking I/O is possible by using the
82 operation to enable the
84 open file status flag.
86 The communication channel provided by a pipe is a
88 there is no concept of message boundaries.
90 If all file descriptors referring to the write end of a pipe
91 have been closed, then an attempt to
93 from the pipe will see end-of-file
96 If all file descriptors referring to the read end of a pipe
97 have been closed, then a
101 signal to be generated for the calling process.
102 If the calling process is ignoring this signal, then
106 An application that uses
112 calls to close unnecessary duplicate file descriptors;
113 this ensures that end-of-file and
115 are delivered when appropriate.
117 It is not possible to apply
121 A pipe has a limited capacity.
122 If the pipe is full, then a
124 will block or fail, depending on whether the
126 flag is set (see below).
127 Different implementations have different limits for the pipe capacity.
128 Applications should not rely on a particular capacity:
129 an application should be designed so that a reading process consumes data
130 as soon as it is available,
131 so that a writing process does not remain blocked.
133 In Linux versions before 2.6.11, the capacity of a pipe was the same as
134 the system page size (e.g., 4096 bytes on i386).
135 Since Linux 2.6.11, the pipe capacity is 65536 bytes.
137 POSIX.1-2001 says that
141 bytes must be atomic: the output data is written to the pipe as a
145 bytes may be nonatomic: the kernel may interleave the data
146 with data written by other processes.
147 POSIX.1-2001 requires
149 to be at least 512 bytes.
153 The precise semantics depend on whether the file descriptor is nonblocking
155 whether there are multiple writers to the pipe, and on
157 the number of bytes to be written:
159 \fBO_NONBLOCK\fP disabled, \fIn\fP <= \fBPIPE_BUF\fP
162 bytes are written atomically;
164 may block if there is not room for
166 bytes to be written immediately
168 \fBO_NONBLOCK\fP enabled, \fIn\fP <= \fBPIPE_BUF\fP
169 If there is room to write
171 bytes to the pipe, then
173 succeeds immediately, writing all
182 \fBO_NONBLOCK\fP disabled, \fIn\fP > \fBPIPE_BUF\fP
183 The write is nonatomic: the data given to
185 may be interleaved with
192 bytes have been written.
194 \fBO_NONBLOCK\fP enabled, \fIn\fP > \fBPIPE_BUF\fP
195 If the pipe is full, then
203 bytes may be written (i.e., a "partial write" may occur;
204 the caller should check the return value from
206 to see how many bytes were actually written),
207 and these bytes may be interleaved with writes by other processes.
208 .SS Open file status flags
209 The only open file status flags that can be meaningfully applied to
217 flag for the read end of a pipe causes a signal
219 by default) to be generated when new input becomes available on the pipe
225 is supported for pipes and FIFOs only since kernel 2.6.
226 .SS Portability notes
227 On some systems (but not Linux), pipes are bidirectional:
228 data can be transmitted in both directions between the pipe ends.
229 According to POSIX.1-2001, pipes only need to be unidirectional.
230 Portable applications should avoid reliance on
231 bidirectional pipe semantics.