Pipes are simply two connected filehandles, where data written to one filehandle can be read by the other. The
pipe
function creates two filehandles linked in this way, one writable and one readable. Even though you can't take two already existing filehandles and link them,
pipe
can be used for communication between processes. One process creates a pair of filehandles with the
pipe
functions, then forks off a child, resulting in two distinct processes both running in the same program, each with a copy of the connected filehandles.

It doesn't matter which process is the reader and which is the writer, so long as one of them takes one role and its peer process takes the other. You can only have one-way communication. (But read on.)

We'll pull in the IO::Handle module so we can call its
autoflush()
method. (You could instead play the
select
games described in
Chapter 7,
File Access
, if you prefer a lightweight solution.) If we didn't, our single line of output would get lodged in the pipe and not make it through to the other side until we closed that handle.

The version of the parent writing to the child is shown in
Example 16.3
.

In the examples in this recipe, most error checking has been left as an exercise for the reader. This is so you can more clearly see how the functions interact. In real life, test the return values of all system calls.

The version of the child writing to the parent is shown in
Example 16.4
.

In most code, both halves would go into loops, with the reader continuing to read until end of file. This happens when the writer closes or exits.

Because piped filehandles are not bidirectional, each process uses just one of the pair and closes the filehandle it doesn't use. The reason is subtle; picture the situation where the reader does not close the writable filehandle. If the writer then exits while the reader is trying to read something, the reader will hang forever. This is because the system won't tell the reader that there's no more data to be read until all copies of the writable filehandle are closed.

The
open
function, when passed as its second argument either
"-|"
or
"|-"
will implicitly pipe and fork. This makes the piping code above slightly easier. The child talks to the parent over STDIN or STDOUT, depending on whether
"-|"
or
"|-"
was used.

Using
open
this way, if the parent wants to write to the child, it does something like what's shown in
Example 16.5
.

Again, since the child already has its STDOUT connected to the parent, this child could
exec
some other program to produce something interesting on its standard output. That output would be available to the parent as input from <
CHILD>
.

When using
open
this way, we don't have to manually call
waitpid
since we didn't do a manual fork. We do have to call
close
, though. In both cases, the
$?
variable will have the child's wait status in it (see
Recipe 16.19
to see how to interpret this status value).

The preceding examples were unidirectional. What if you want both processes talking to each other? Just make two calls to
pipe
before forking. You must be careful about who tells whom what and when, though, or you're apt to deadlock. (See
Example 16.7
.)

That's getting complicated. It just so happens that there's a special system call, shown in
Example 16.8
, that makes the last example simpler. It's called
socketpair
, and it works like
pipe
, except that both handles can be used for reading and for writing.

On Linux kernels before 2.0.34, the
shutdown (2)
system call was broken. Instead of telling the reader not to write and the writer not to read, you had to tell the reader not to read and the writer not to write.