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 2014-07-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 filesystem
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 filesystem,
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.
136 Since Linux 2.6.35, the default pipe capacity is 65536 bytes,
137 but the capacity can be queried and set using the
145 for more information.
148 POSIX.1-2001 says that
152 bytes must be atomic: the output data is written to the pipe as a
156 bytes may be nonatomic: the kernel may interleave the data
157 with data written by other processes.
158 POSIX.1-2001 requires
160 to be at least 512 bytes.
164 The precise semantics depend on whether the file descriptor is nonblocking
166 whether there are multiple writers to the pipe, and on
168 the number of bytes to be written:
170 \fBO_NONBLOCK\fP disabled, \fIn\fP <= \fBPIPE_BUF\fP
173 bytes are written atomically;
175 may block if there is not room for
177 bytes to be written immediately
179 \fBO_NONBLOCK\fP enabled, \fIn\fP <= \fBPIPE_BUF\fP
180 If there is room to write
182 bytes to the pipe, then
184 succeeds immediately, writing all
193 \fBO_NONBLOCK\fP disabled, \fIn\fP > \fBPIPE_BUF\fP
194 The write is nonatomic: the data given to
196 may be interleaved with
203 bytes have been written.
205 \fBO_NONBLOCK\fP enabled, \fIn\fP > \fBPIPE_BUF\fP
206 If the pipe is full, then
214 bytes may be written (i.e., a "partial write" may occur;
215 the caller should check the return value from
217 to see how many bytes were actually written),
218 and these bytes may be interleaved with writes by other processes.
219 .SS Open file status flags
220 The only open file status flags that can be meaningfully applied to
228 flag for the read end of a pipe causes a signal
230 by default) to be generated when new input becomes available on the pipe
236 is supported for pipes and FIFOs only since kernel 2.6.
237 .SS Portability notes
238 On some systems (but not Linux), pipes are bidirectional:
239 data can be transmitted in both directions between the pipe ends.
240 According to POSIX.1-2001, pipes only need to be unidirectional.
241 Portable applications should avoid reliance on
242 bidirectional pipe semantics.
256 This page is part of release 3.78 of the Linux
259 A description of the project,
260 information about reporting bugs,
261 and the latest version of this page,
263 \%http://www.kernel.org/doc/man\-pages/.
OSDN Git Service
