PIPE(7)                   (2017-09-15)                    PIPE(7)

          pipe - overview of pipes and FIFOs

          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 communication 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 operations on the underlying device (if there is

        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

     Page 1                        Linux             (printed 5/22/22)

     PIPE(7)                   (2017-09-15)                    PIPE(7)

          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 implementa-
          tions have different limits for the pipe capacity.  Applica-
          tions should not rely on a particular capacity: an applica-
          tion 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 i386).
          Since Linux 2.6.11, the pipe capacity is 16 pages (i.e.,
          65,536 bytes in a system with a page size of 4096 bytes).
          Since Linux 2.6.35, the default pipe capacity is 16 pages,
          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.

          The following ioctl(2) operation, which can be applied to a
          file descriptor that refers to either end of a pipe, places
          a count of the number of unread bytes in the pipe in the int
          buffer pointed to by the final argument of the call:

              ioctl(fd, FIONREAD, &nbytes);

          The FIONREAD operation is not specified in any standard, but
          is provided on many implementations.

        /proc files
          On Linux, the following files control how much memory can be
          used for pipes:




          htmlmanrefstart/proc/sys/fs/pipe-user-pages-hard(sinceLinux4.5)    .}f The hard limit on the total size (in pages) of all
               pipes created or set by a single unprivileged user
               (i.e., one with neither the CAP_SYS_RESOURCE nor the
               CAP_SYS_ADMIN capability).  So long as the total number
               of pages allocated to pipe buffers for this user is at
               this limit, attempts to create new pipes will be
               denied, and attempts to increase a pipe's capacity will
               be denied.

               When the value of this limit is zero (which is the
               default), no hard limit is applied.


          htmlmanrefstartpipe-user-pages-softhtmlmanrefendpipe-user-pages-soft htmlmanrefstartpipe-user-pages-hardhtmlmanrefendpipe-user-pages-hard

        html<H4>    html</H4>


        html<H4>    html</H4>

        html<H4>    html</H4>

        html<H4>    html</H4>

          htmlmanrefstartpipe-user-pages-softhtmlmanrefendpipe-user-pages-soft htmlmanrefstartpipe-user-pages-hardhtmlmanrefendpipe-user-pages-hard

     html<H4>    html</H4>

     html<H4>    html</H4>