'''See also:'''
   * [fifo]
   * Wikipedia entry [http://en.wikipedia.org/wiki/Named_pipe]
   * The Linux Programmer's Guide: Named Pipes [http://www.tldp.org/LDP/lpg/node15.html]

''Adapted (read; ripped with some minor editing) from a Linux man-page: pipe (7)''

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 FIFO (short for First In First Out) has a name within the file system, and is opened as a regular file.  Any process may open a FIFO, assuming the file permissions allow it, and may then read or write to it as appropriate.

'''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.

The communication channel provided by a pipe is a byte stream: there is no concept of message boundaries.

'''Pipe Capacity'''
A pipe has a limited capacity.  If the pipe is full, then a write will block or fail, depending on whether the pipe was opened in non-blocking mode.  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.

'''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, pipes only need to be unidirectional.  Portable applications should avoid reliance on bidirectional pipe semantics.

----
''Adapted from another Linux man-page: fifo (4)''

A FIFO special file (a named pipe) is similar to a pipe, except that it is accessed as part of the file system. It can be opened by multiple processes for reading or writing. When processes are exchanging data via the FIFO, the kernel passes all data internally without writing it to the file system. Thus, the FIFO special file has no contents on the file system, the file system entry merely serves as a reference point so that processes can access the pipe using a name in the file system. 

The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also. 

A process can open a FIFO in non-blocking mode:
   open $fifoname {RDONLY NONBLOCK}
In this case, opening for read only will succeed even if noone has opened on the write side yet; opening for write only 
   open $fifoname {WRONLY NONBLOCK}
''will fail with ENXIO'' (no such device or address) ''unless the other end has already been opened.'' 
Merely opening in non-blocking mode will not configure the channel to be non-blocking; use [fconfigure] for that.

Under [Linux], opening a FIFO for read and write will succeed both in blocking and non-blocking mode. POSIX leaves this behaviour undefined. This can be used to open a FIFO for writing while there are no readers available. A process that uses both ends of the connection in order to communicate with itself should be very careful to avoid deadlocks.

When a process tries to write to a FIFO that is not opened for read on the other side, the process is sent a SIGPIPE signal. Tcl responds by having the command (typically [puts]) throw an error with the following errorCode:
  POSIX EPIPE {broken pipe}

----
[[
[Category File] |
[Category Interprocess Communication] |
[Category Channel]
]]