Named pipes

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() share|improve this answer

edited May 23 at 12:39

answered Mar 25 '13 at 11:15

mr.spuratic

5,731922

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 1 '15 at 2:41

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.

+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

@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

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

News	Pipes -- powerful and elegant programming paradigm	Recommended Links	Advanced Piping	Unix Sockets	Filters	Coroutines	Unix Sockets
Pipes support in Unix shell	Coroutines in shell	Pipes in Perl	Pipes support in Python	Coroutines in Assember	Pipes in vi/vim	Coroutines in C	Coroutines in C++
cut	tr	expand	tee	script	head	sort	uniq
awk one liners	perl one liners	netcat	pv - pipe viewer	Regex	xargs
Software Engineering	Unix Component Model	Sysadmin Horror Stories	Tips	History	Humor	Random Findings	Etc

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

Named pipes

NEWS CONTENTS

Old News ;-)

What are the advantages of using named pipe over unnamed pipe - Unix & Linux Stack Exchange

What are the advantages of using named pipe over unnamed pipe - Unix & Linux Stack Exchange

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Etc