62

I was reviewing a set of interview questions that are asked from a unix admin; I found a topic called "named pipe".

I googled the topic; to some extent I have been able to understand it :- named pipes || FIFO

But still I feel that I am lacking the knowledge of when to use this particular type of pipe. Are there any special situations where unnamed pipes would fail to work ?

Kilian Foth
  • 811
Ankit
  • 1,385
  • Another link on technical forum: http://www.writeulearn.com/category/inter-process-communicationipc/ –  Oct 16 '14 at 16:25

4 Answers4

48

Named pipes (fifo) have four three advantages I can think of:

  • you don't have to start the reading/writing processes at the same time
  • you can have multiple readers/writers which do not need common ancestry
  • as a file you can control ownership and permissions

  • they are bi-directional, unnamed pipes may be unidirectional *

    *) Think of a standard shell | pipeline which is unidirectional, several shells (ksh, zsh, and bash) also offer coprocesses which allow bi-directional communication. POSIX treats pipes as half-duplex (i.e. each side can only read or write), the pipe() system call returns two file handles and you may be required to treat one as read-only and the other as write-only. Some (BSD) systems support read and write simultaneously (not forbidden by POSIX), on others you would need two pipes, one for each direction. Check your pipe(), popen() and possibly popen2() man pages. The undirectionality may not be dependent on whether the pipe is named or not, though on Linux 2.6 it is dependent.

(Updated, thanks to feedback from Stephane Chazelas)

So one immediately obvious task you cannot achieve with an unnamed pipe is a conventional client/server application.

The last (stricken) point above about unidirectional pipes is relevant on Linux, POSIX (see popen()) says that a pipe need only be readable or writeable, on Linux they are unidirectional. See Understanding The Linux Kernel (3rd Ed. O'Reilly) for Linux-specific details (p787). Other OS's offer bidirectional (unnamed) pipes.

As an example, Nagios uses a fifo for its command file. Various external processes (CGI scripts, external checks, NRPE etc) write commands/updates to this fifo and these are processed by the persistent Nagios process.

Named pipes have features not unlike TCP connections, but there are important differences. Because a fifo has a persistent filesystem name you can write to it even when there is no reader, admittedly the writes will block (without async or non-blocking I/O), though you won't loose data if the receiver isn't started (or is being restarted).

For reference, see also Unix domain sockets, and the answer to this Stackoverflow question which summarises the main IPC methods, and this one which talks about popen()

Adam Katz
  • 3,965
mr.spuratic
  • 9,901
  • 4
    you can have multiple readers/writers with unnamed pipes as well. On Linux, they are not any more bi-directional than unamed pipe. There's a writing end and a reading end and data flows in one direction only. When you open a fifo in write mode, you get the writing end, in read mode the reading end, in rw mode, you write to the writing end and read from the reading. That's different from bi-directional pipes or unix domain sockets, where you actually have two separate flows of data in each direction. – Stéphane Chazelas Mar 25 '13 at 21:03
  • @StephaneChazelas thanks for the feedback, I have updated the answer to be more specific, and clarify (I hope) pipes and directionality. – mr.spuratic Mar 25 '13 at 23:03
  • Does communication to a named pipe involve disk IO? Or is it all in-memory? What determines the performance envelope of these IPC mechanisms? – CMCDragonkai May 01 '15 at 02:41
19

Unnamed or anonymous pipes provide a means of one-to-one, one-way interprocess communication between different processes that are related by either a parent-child relationship, or by being children of a common parent that provides the pipe, such as a shell process. Because the processes are related, the association of file descriptors to the pipe can be implicit and does not require an object with a name that is external to the processes. An unnamed pipe exists only as long as the processess that use it maintain open file descriptors to the pipe. When the processes exit and the OS closes all of the file descriptors associated with the processes, the unnamed pipe is closed.

Named pipes are in fact FIFO's. These are persistent objects represented by nodes in the file system. A named pipe provides many-to-many, two-way communication between one or more processes that are not necessarily related and do not need to exist at the same time. The file name of the pipe serves as an address or contract between the processes for communication. If only one process writes to a named pipe and one other process reads from the named pipe, then the named pipe behaves in the same way as an unnamed pipe between the two related processes.

So the short answer is that you need a named pipe for communication between unrelated processes that might not exist at the same time.

Jonathan Ben-Avraham
  • 2,274
  • +1 I think the processes pretty much always exist at the same time (otherwise the pipe is a little pointless -- you might as well just leave stuff in a regular file). These and unix domain sockets are often used by daemon services that can be controlled, eg, from the command line. If you look in /run on a linux desktop system you'll probably find a few of both (named fifos and unix sockets). It's a form of IPC. – goldilocks Mar 25 '13 at 12:10
  • 2
    @goldilocks: A named pipe is commonly used as a memory-resident ad-hoc mailbox between processes in embedded systems, where the communicating processes are short-lived and do not exist at the same time. The advantage is the simplicity of the implementation versus shared memory IPC and the fact that only RAM is used. The disadvantage is the non-persistence between boots and the byte-wise FIFO nature of the pipe versus the ability to use a structure with shared memory. – Jonathan Ben-Avraham Mar 25 '13 at 12:31
  • @jonathan: +1, I have some doubts:- why do we refer named pipes as FIFO ; what are persistant objects ? – Ankit Mar 25 '13 at 16:23
  • @Ankit: Some people call a named pipe a FIFO because it behaves like a FIFO data structure, especially when opened for both reading and writing by a single process. By "persistent object" I meant that a named pipe is associated with a file system object. That is, it is a type of file, with a name, and it has the same persistence as any other file stored on the media. – Jonathan Ben-Avraham Mar 26 '13 at 17:26
7

There is another advantage of named pipes: you can use them across different systems. Suppose you want real-time communication of two process running on different machines. Then share a folder between the two, put your FIFO onto the folder, and off you go. It is considerably easier than transforming an application designed to work on files into a service listening on a port.

MariusMatutiae
  • 4,372
  • 1
  • 25
  • 36
5

One advantage not mentioned elsewhere is that a named pipe can be used in places where only a file will do.

For example, some email clients have the feature of appending the contents of ~/.signature to every mail message. If .signature were a command-line option or if the mail client were able to notice that .signature is executable and run it, then you wouldn't need a named pipe. But if the mail client isn't that sophisticated, you can make a named pipe called .signature and run an application that generates a new signature every time that the file is read.

Eyal
  • 151
  • Interesting. Do you have such an application? It seems it would have to watch at the kernel level to see when the FIFO was being accessed. – Wildcard Apr 19 '16 at 02:34