Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
PIPE(7)			   Linux Programmer's Manual		       PIPE(7)

NAME
       pipe - overview of pipes	and FIFOs

DESCRIPTION
       Pipes  and  FIFOs  (also	known as named pipes) provide a	unidirectional
       interprocess communication channel.  A pipe has a read end and a	 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	commu-
       nication	channel	between	related	processes; see pipe(2) for an example.

       A  FIFO (short for First	In First Out) has a name within	the filesystem
       (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.  Note:	although FIFOs
       have a pathname in the filesystem, I/O on FIFOs does not	involve	opera-
       tions 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.   Nonblocking
       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 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 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 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 re-
       main 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 i386).	 Since	Linux  2.6.11,
       the pipe	capacity is 65536 bytes.  Since	Linux 2.6.35, the default pipe
       capacity	is 65536 bytes,	but the	capacity can be	queried	and set	 using
       the  fcntl(2)  F_GETPIPE_SZ  and	F_SETPIPE_SZ operations.  See fcntl(2)
       for more	information.

   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 se-
       quence.	Writes of more than PIPE_BUF bytes may be nonatomic: the  ker-
       nel  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 nonblocking (O_NONBLOCK), whether there are multiple
       writers to the pipe, and	on n, the number of bytes to be	written:

       O_NONBLOCK disabled, n <= PIPE_BUF
	      All  n bytes are written atomically; write(2) may	block if there
	      is not room for n	bytes to be written immediately

       O_NONBLOCK enabled, n <=	PIPE_BUF
	      If there is room to write	n bytes	to  the	 pipe,	then  write(2)
	      succeeds	immediately,  writing  all n bytes; otherwise write(2)
	      fails, with errno	set to EAGAIN.

       O_NONBLOCK disabled, n >	PIPE_BUF
	      The write	is nonatomic: the data given to	write(2) may be	inter-
	      leaved  with write(2)s by	other process; the write(2) blocks un-
	      til n bytes have been written.

       O_NONBLOCK enabled, n > PIPE_BUF
	      If the pipe is full, then	write(2) fails,	with errno set to  EA-
	      GAIN.   Otherwise,  from	1  to  n bytes may be written (i.e., a
	      "partial write" may occur; the caller should  check  the	return
	      value  from  write(2)  to	see how	many bytes were	actually writ-
	      ten), and	these bytes may	be interleaved with  writes  by	 other
	      processes.

   Open	file status flags
       The  only  open file status flags that can be meaningfully applied to a
       pipe or FIFO are	O_NONBLOCK and O_ASYNC.

       Setting the O_ASYNC flag	for the	read end of a  pipe  causes  a	signal
       (SIGIO  by default) to be generated when	new input becomes available on
       the pipe	(see fcntl(2) for details).  On	Linux,	O_ASYNC	 is  supported
       for pipes and FIFOs only	since kernel 2.6.

   Portability notes
       On  some	 systems (but not Linux), pipes	are bidirectional: data	can be
       transmitted in both directions between the  pipe	 ends.	 According  to
       POSIX.1-2001,  pipes only need to be unidirectional.  Portable applica-
       tions should avoid reliance on bidirectional pipe semantics.

SEE ALSO
       dup(2), fcntl(2), open(2), pipe(2), poll(2), select(2),	socketpair(2),
       stat(2),	mkfifo(3), epoll(7), fifo(7)

COLOPHON
       This  page  is  part of release 3.74 of the Linux man-pages project.  A
       description of the project, information about reporting bugs,  and  the
       latest	  version     of     this    page,    can    be	   found    at
       http://www.kernel.org/doc/man-pages/.

Linux				  2014-07-08			       PIPE(7)

NAME | DESCRIPTION | SEE ALSO | COLOPHON

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=pipe&sektion=7&manpath=Debian+8.1.0>

home | help