-So, always explicitly and immediately call close() on the writable end
-of any pipe, unless that process is actually writing to it. If you
-don't explicitly call close() then be warned Perl will still close()
-all the filehandles during global destruction. As warned above, if
-those filehandles were opened with Safe Pipe Open, they will also call
-waitpid() and you might again deadlock.
+ @grep_args = ("egrep", "-i", $some_pattern, @many_files);
+ open(GREP_PIPE, "-|", @grep_args)
+ || die "can't open @grep_args|: $!";
+
+Here the multi-argument form of pipe open() is preferred because the
+pattern and indeed even the filenames themselves might hold metacharacters.
+
+Be aware that these operations are full Unix forks, which means they may
+not be correctly implemented on all alien systems. Additionally, these are
+not true multithreading. To learn more about threading, see the F<modules>
+file mentioned below in the SEE ALSO section.
+
+=head2 Avoiding Pipe Deadlocks
+
+Whenever you have more than one subprocess, you must be careful that each
+closes whichever half of any pipes created for interprocess communication
+it is not using. This is because any child process reading from the pipe
+and expecting an EOF will never receive it, and therefore never exit. A
+single process closing a pipe is not enough to close it; the last process
+with the pipe open must close it for it to read EOF.
+
+Certain built-in Unix features help prevent this most of the time. For
+instance, filehandles have a "close on exec" flag, which is set I<en masse>
+under control of the C<$^F> variable. This is so any filehandles you
+didn't explicitly route to the STDIN, STDOUT or STDERR of a child
+I<program> will be automatically closed.
+
+Always explicitly and immediately call close() on the writable end of any
+pipe, unless that process is actually writing to it. Even if you don't
+explicitly call close(), Perl will still close() all filehandles during
+global destruction. As previously discussed, if those filehandles have
+been opened with Safe Pipe Open, this will result in calling waitpid(),
+which may again deadlock.