Pipes and FIFOs (also known as named pipes)
provide a unidirectional interprocess communication channel.
A pipe has a
read end
and a
R write end .
Data written to the write end of a pipe can be read
from the read end of the pipe.
A pipe is created using
pipe(2),
which creates a new pipe and returns two file descriptors,
one referring to the read end of the pipe,
the other referring to the write end.
Pipes can be used to create a communication channel between related
processes; see
pipe(2)
for an example.
A FIFO (short for First In First Out) has a name within the file
system (created using
mkfifo(3)),
and is opened using
open(2).
Any process may open a FIFO, assuming the file permissions allow it.
The read end is opened using the
O_RDONLY
flag; the write end is opened using the
O_WRONLY
flag.
See
fifo(7)
for further details.
R Note :
although FIFOs have a pathname in the file system,
I/O on FIFOs does not involve operations on the underlying device
(if there is one).
I/O on Pipes and FIFOs
The only difference between pipes and FIFOs is the manner in which
they are created and opened.
Once these tasks have been accomplished,
I/O on pipes and FIFOs has exactly the same semantics.
If a process attempts to read from an empty pipe, then
read(2)
will block until data is available.
If a process attempts to write to a full pipe (see below), then
write(2)
blocks until sufficient data has been read from the pipe
to allow the write to complete.
Non-blocking I/O is possible by using the
fcntl(2)
F_SETFL
operation to enable the
O_NONBLOCK
open file status flag.
The communication channel provided by a pipe is a
R byte stream :
there is no concept of message boundaries.
If all file descriptors referring to the write end of a pipe
have been closed, then an attempt to
read(2)
from the pipe will see end-of-file
(read(2)
will return 0).
If all file descriptors referring to the read end of a pipe
have been closed, then a
write(2)
will cause a
SIGPIPE
signal to be generated for the calling process.
If the calling process is ignoring this signal, then
write(2)
fails with the error
R EPIPE .
An application that uses
pipe(2)
and
fork(2)
should use suitable
close(2)
calls to close unnecessary duplicate file descriptors;
this ensures that end-of-file and
R SIGPIPE / EPIPE
are delivered when appropriate.
It is not possible to apply
lseek(2)
to a pipe.
Pipe Capacity
A pipe has a limited capacity.
If the pipe is full, then a
write(2)
will block or fail, depending on whether the
O_NONBLOCK
flag is set (see below).
Different implementations have different limits for the pipe capacity.
Applications should not rely on a particular capacity:
an application should be designed so that a reading process consumes data
as soon as it is available,
so that a writing process does not remain blocked.
In Linux versions before 2.6.11, the capacity of a pipe was the same as
the system page size (e.g., 4096 bytes on x86).
Since Linux 2.6.11, the pipe capacity is 65536 bytes.
PIPE_BUF
POSIX.1-2001 says that
write(2)s
of less than
PIPE_BUF
bytes must be atomic: the output data is written to the pipe as a
contiguous sequence.
Writes of more than
PIPE_BUF
bytes may be non-atomic: the kernel may interleave the data
with data written by other processes.
POSIX.1-2001 requires
PIPE_BUF
to be at least 512 bytes.
(On Linux,
PIPE_BUF
is 4096 bytes.)
The precise semantics depend on whether the file descriptor is non-blocking
(O_NONBLOCK),
whether there are multiple writers to the pipe, and on
R n ,
the number of bytes to be written:
ČLÁNKY DO MAILU