<P>perlipc - Perl interprocess communication (signals, fifos, pipes, safe subprocesses, sockets, and semaphores)</P>
<P>
<HR>
<H1><A NAME="description">DESCRIPTION</A></H1>
<P>The basic IPC facilities of Perl are built out of the good old Unix
signals, named pipes, pipe opens, the Berkeley socket routines, and SysV
IPC calls. Each is used in slightly different situations.</P>
<P>
<HR>
<H1><A NAME="signals">Signals</A></H1>
<P>Perl uses a simple signal handling model: the %SIG hash contains names or
references of user-installed signal handlers. These handlers will be called
with an argument which is the name of the signal that triggered it. A
signal may be generated intentionally from a particular keyboard sequence like
control-C or control-Z, sent to you from another process, or
triggered automatically by the kernel when special events transpire, like
a child process exiting, your process running out of stack space, or
hitting file size limit.</P>
<P>For example, to trap an interrupt signal, set up a handler like this.
Do as little as you possibly can in your handler; notice how all we do is
set a global variable and then raise an exception. That's because on most
systems, libraries are not re-entrant; particularly, memory allocation and
I/O routines are not. That means that doing nearly <EM>anything</EM> in your
handler could in theory trigger a memory fault and subsequent core dump.</P>
<PRE>
sub catch_zap {
my $signame = shift;
$shucks++;
die "Somebody sent me a SIG$signame";
}
$SIG{INT} = 'catch_zap'; # could fail in modules
$SIG{INT} = \&catch_zap; # best strategy</PRE>
<P>The names of the signals are the ones listed out by <CODE>kill -l</CODE> on your
system, or you can retrieve them from the Config module. Set up an
@signame list indexed by number to get the name and a %signo table
indexed by name to get the number:</P>
<PRE>
use Config;
defined $Config{sig_name} || die "No sigs?";
foreach $name (split(' ', $Config{sig_name})) {
$signo{$name} = $i;
$signame[$i] = $name;
$i++;
}</PRE>
<P>So to check whether signal 17 and SIGALRM were the same, do just this:</P>
<PRE>
print "signal #17 = $signame[17]\n";
if ($signo{ALRM}) {
print "SIGALRM is $signo{ALRM}\n";
}</PRE>
<P>You may also choose to assign the strings <CODE>'IGNORE'</CODE> or <CODE>'DEFAULT'</CODE> as
the handler, in which case Perl will try to discard the signal or do the
default thing.</P>
<P>On most Unix platforms, the <CODE>CHLD</CODE> (sometimes also known as <CODE>CLD</CODE>) signal
has special behavior with respect to a value of <CODE>'IGNORE'</CODE>.
Setting <CODE>$SIG{CHLD}</CODE> to <CODE>'IGNORE'</CODE> on such a platform has the effect of
not creating zombie processes when the parent process fails to <A HREF="../../lib/Pod/perlfunc.html#item_wait"><CODE>wait()</CODE></A>
on its child processes (i.e. child processes are automatically reaped).
Calling <A HREF="../../lib/Pod/perlfunc.html#item_wait"><CODE>wait()</CODE></A> with <CODE>$SIG{CHLD}</CODE> set to <CODE>'IGNORE'</CODE> usually returns
<CODE>-1</CODE> on such platforms.</P>
<P>Some signals can be neither trapped nor ignored, such as
the KILL and STOP (but not the TSTP) signals. One strategy for
temporarily ignoring signals is to use a <A HREF="../../lib/Pod/perlfunc.html#item_local"><CODE>local()</CODE></A> statement, which will be
automatically restored once your block is exited. (Remember that <A HREF="../../lib/Pod/perlfunc.html#item_local"><CODE>local()</CODE></A>
values are ``inherited'' by functions called from within that block.)</P>
<PRE>
sub precious {
local $SIG{INT} = 'IGNORE';
&more_functions;
}
sub more_functions {
# interrupts still ignored, for now...
}</PRE>
<P>Sending a signal to a negative process ID means that you send the signal
to the entire Unix process-group. This code sends a hang-up signal to all
processes in the current process group (and sets $SIG{HUP} to IGNORE so
it doesn't kill itself):</P>
<PRE>
{
local $SIG{HUP} = 'IGNORE';
kill HUP => -$$;
# snazzy writing of: kill('HUP', -$$)
}</PRE>
<P>Another interesting signal to send is signal number zero. This doesn't
actually affect another process, but instead checks whether it's alive
or has changed its UID.</P>
<PRE>
unless (kill 0 => $kid_pid) {
warn "something wicked happened to $kid_pid";
}</PRE>
<P>You might also want to employ anonymous functions for simple signal
handlers:</P>
<PRE>
$SIG{INT} = sub { die "\nOutta here!\n" };</PRE>
<P>But that will be problematic for the more complicated handlers that need
to reinstall themselves. Because Perl's signal mechanism is currently
based on the <CODE>signal(3)</CODE> function from the C library, you may sometimes be so
misfortunate as to run on systems where that function is ``broken'', that
is, it behaves in the old unreliable SysV way rather than the newer, more
reasonable BSD and POSIX fashion. So you'll see defensive people writing
signal handlers like this:</P>
<PRE>
sub REAPER {
$waitedpid = wait;
# loathe sysV: it makes us not only reinstate
# the handler, but place it after the wait
$SIG{CHLD} = \&REAPER;
}
$SIG{CHLD} = \&REAPER;
# now do something that forks...</PRE>
<P>or even the more elaborate:</P>
<PRE>
use POSIX ":sys_wait_h";
sub REAPER {
my $child;
while (($child = waitpid(-1,WNOHANG)) > 0) {
$Kid_Status{$child} = $?;
}
$SIG{CHLD} = \&REAPER; # still loathe sysV
}
$SIG{CHLD} = \&REAPER;
# do something that forks...</PRE>
<P>Signal handling is also used for timeouts in Unix, While safely
protected within an <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval{}</CODE></A> block, you set a signal handler to trap
alarm signals and then schedule to have one delivered to you in some
number of seconds. Then try your blocking operation, clearing the alarm
when it's done but not before you've exited your <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval{}</CODE></A> block. If it
goes off, you'll use <A HREF="../../lib/Pod/perlfunc.html#item_die"><CODE>die()</CODE></A> to jump out of the block, much as you might
using <CODE>longjmp()</CODE> or <CODE>throw()</CODE> in other languages.</P>
<P>Here's an example:</P>
<PRE>
eval {
local $SIG{ALRM} = sub { die "alarm clock restart" };
alarm 10;
flock(FH, 2); # blocking write lock
alarm 0;
};
if ($@ and $@ !~ /alarm clock restart/) { die }</PRE>
<P>If the operation being timed out is <A HREF="../../lib/Pod/perlfunc.html#item_system"><CODE>system()</CODE></A> or qx(), this technique
is liable to generate zombies. If this matters to you, you'll
need to do your own <A HREF="../../lib/Pod/perlfunc.html#item_fork"><CODE>fork()</CODE></A> and exec(), and kill the errant child process.</P>
<P>For more complex signal handling, you might see the standard POSIX
module. Lamentably, this is almost entirely undocumented, but
the <EM>t/lib/posix.t</EM> file from the Perl source distribution has some
examples in it.</P>
<P>
<HR>
<H1><A NAME="named pipes">Named Pipes</A></H1>
<P>A named pipe (often referred to as a FIFO) is an old Unix IPC
mechanism for processes communicating on the same machine. It works
just like a regular, connected anonymous pipes, except that the
processes rendezvous using a filename and don't have to be related.</P>
<P>To create a named pipe, use the Unix command <CODE>mknod(1)</CODE> or on some
systems, mkfifo(1). These may not be in your normal path.</P>
<PRE>
# system return val is backwards, so && not ||
#
$ENV{PATH} .= ":/etc:/usr/etc";
if ( system('mknod', $path, 'p')
&& system('mkfifo', $path) )
{
die "mk{nod,fifo} $path failed";
}</PRE>
<P>A fifo is convenient when you want to connect a process to an unrelated
one. When you open a fifo, the program will block until there's something
on the other end.</P>
<P>For example, let's say you'd like to have your <EM>.signature</EM> file be a
named pipe that has a Perl program on the other end. Now every time any
program (like a mailer, news reader, finger program, etc.) tries to read
from that file, the reading program will block and your program will
supply the new signature. We'll use the pipe-checking file test <STRONG>-p</STRONG>
to find out whether anyone (or anything) has accidentally removed our fifo.</P>
<PRE>
chdir; # go home
$FIFO = '.signature';
$ENV{PATH} .= ":/etc:/usr/games";</PRE>
<PRE>
while (1) {
unless (-p $FIFO) {
unlink $FIFO;
system('mknod', $FIFO, 'p')
&& die "can't mknod $FIFO: $!";
}</PRE>
<PRE>
# next line blocks until there's a reader
open (FIFO, "> $FIFO") || die "can't write $FIFO: $!";
print FIFO "John Smith (smith\@host.org)\n", `fortune -s`;
close FIFO;
sleep 2; # to avoid dup signals
}</PRE>
<P>
<H2><A NAME="warning">WARNING</A></H2>
<P>By installing Perl code to deal with signals, you're exposing yourself
to danger from two things. First, few system library functions are
re-entrant. If the signal interrupts while Perl is executing one function
(like <CODE>malloc(3)</CODE> or printf(3)), and your signal handler then calls the
same function again, you could get unpredictable behavior--often, a
core dump. Second, Perl isn't itself re-entrant at the lowest levels.
If the signal interrupts Perl while Perl is changing its own internal
data structures, similarly unpredictable behaviour may result.</P>
<P>There are two things you can do, knowing this: be paranoid or be
pragmatic. The paranoid approach is to do as little as possible in your
signal handler. Set an existing integer variable that already has a
value, and return. This doesn't help you if you're in a slow system call,
which will just restart. That means you have to <A HREF="../../lib/Pod/perlfunc.html#item_die"><CODE>die</CODE></A> to <CODE>longjump(3)</CODE> out
of the handler. Even this is a little cavalier for the true paranoiac,
who avoids <A HREF="../../lib/Pod/perlfunc.html#item_die"><CODE>die</CODE></A> in a handler because the system <EM>is</EM> out to get you.
The pragmatic approach is to say ``I know the risks, but prefer the
convenience'', and to do anything you want in your signal handler,
prepared to clean up core dumps now and again.</P>
<P>To forbid signal handlers altogether would bars you from
many interesting programs, including virtually everything in this manpage,
since you could no longer even write SIGCHLD handlers. Their dodginess
is expected to be addresses in the 5.005 release.</P>
<P>
<HR>
<H1><A NAME="using open() for ipc">Using <A HREF="../../lib/Pod/perlfunc.html#item_open"><CODE>open()</CODE></A> for IPC</A></H1>
<P>Perl's basic <A HREF="../../lib/Pod/perlfunc.html#item_open"><CODE>open()</CODE></A> statement can also be used for unidirectional interprocess
communication by either appending or prepending a pipe symbol to the second
argument to open(). Here's how to start something up in a child process you
intend to write to:</P>
<PRE>
open(SPOOLER, "| cat -v | lpr -h 2>/dev/null")
|| die "can't fork: $!";
local $SIG{PIPE} = sub { die "spooler pipe broke" };
print SPOOLER "stuff\n";
close SPOOLER || die "bad spool: $! $?";</PRE>
<P>And here's how to start up a child process you intend to read from:</P>
<PRE>
open(STATUS, "netstat -an 2>&1 |")
|| die "can't fork: $!";
while (<STATUS>) {
next if /^(tcp|udp)/;
print;
}
close STATUS || die "bad netstat: $! $?";</PRE>
<P>If one can be sure that a particular program is a Perl script that is
expecting filenames in @ARGV, the clever programmer can write something
like this:</P>
<PRE>
% program f1 "cmd1|" - f2 "cmd2|" f3 < tmpfile</PRE>
<P>and irrespective of which shell it's called from, the Perl program will
read from the file <EM>f1</EM>, the process <EM>cmd1</EM>, standard input (<EM>tmpfile</EM>
in this case), the <EM>f2</EM> file, the <EM>cmd2</EM> command, and finally the <EM>f3</EM>
file. Pretty nifty, eh?</P>
<P>You might notice that you could use backticks for much the
same effect as opening a pipe for reading:</P>
<PRE>
print grep { !/^(tcp|udp)/ } `netstat -an 2>&1`;
die "bad netstat" if $?;</PRE>
<P>While this is true on the surface, it's much more efficient to process the
file one line or record at a time because then you don't have to read the
whole thing into memory at once. It also gives you finer control of the
whole process, letting you to kill off the child process early if you'd
like.</P>
<P>Be careful to check both the <A HREF="../../lib/Pod/perlfunc.html#item_open"><CODE>open()</CODE></A> and the <A HREF="../../lib/Pod/perlfunc.html#item_close"><CODE>close()</CODE></A> return values. If
you're <EM>writing</EM> to a pipe, you should also trap SIGPIPE. Otherwise,
think of what happens when you start up a pipe to a command that doesn't
exist: the <A HREF="../../lib/Pod/perlfunc.html#item_open"><CODE>open()</CODE></A> will in all likelihood succeed (it only reflects the
fork()'s success), but then your output will fail--spectacularly. Perl
can't know whether the command worked because your command is actually
running in a separate process whose <A HREF="../../lib/Pod/perlfunc.html#item_exec"><CODE>exec()</CODE></A> might have failed. Therefore,
while readers of bogus commands return just a quick end of file, writers
to bogus command will trigger a signal they'd better be prepared to
handle. Consider:</P>
<PRE>
open(FH, "|bogus") or die "can't fork: $!";
print FH "bang\n" or die "can't write: $!";
close FH or die "can't close: $!";</PRE>
<P>That won't blow up until the close, and it will blow up with a SIGPIPE.
To catch it, you could use this:</P>
<PRE>
$SIG{PIPE} = 'IGNORE';
open(FH, "|bogus") or die "can't fork: $!";
print FH "bang\n" or die "can't write: $!";
close FH or die "can't close: status=$?";</PRE>
<P>
<H2><A NAME="filehandles">Filehandles</A></H2>
<P>Both the main process and any child processes it forks share the same
STDIN, STDOUT, and STDERR filehandles. If both processes try to access
them at once, strange things can happen. You may also want to close
or reopen the filehandles for the child. You can get around this by
opening your pipe with open(), but on some systems this means that the
<P>You can run a command in the background with:</P>
<PRE>
system("cmd &");</PRE>
<P>The command's STDOUT and STDERR (and possibly STDIN, depending on your
shell) will be the same as the parent's. You won't need to catch
SIGCHLD because of the double-fork taking place (see below for more
details).</P>
<P>
<H2><A NAME="complete dissociation of child from parent">Complete Dissociation of Child from Parent</A></H2>
<P>In some cases (starting server processes, for instance) you'll want to
completely dissociate the child process from the parent. This is
often called daemonization. A well behaved daemon will also <A HREF="../../lib/Pod/perlfunc.html#item_chdir"><CODE>chdir()</CODE></A>
to the root directory (so it doesn't prevent unmounting the filesystem
containing the directory from which it was launched) and redirect its
standard file descriptors from and to <EM>/dev/null</EM> (so that random
output doesn't wind up on the user's terminal).</P>
<PRE>
use POSIX 'setsid';</PRE>
<PRE>
sub daemonize {
chdir '/' or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '>/dev/null'
or die "Can't write to /dev/null: $!";
defined(my $pid = fork) or die "Can't fork: $!";
exit if $pid;
setsid or die "Can't start a new session: $!";
open STDERR, '>&STDOUT' or die "Can't dup stdout: $!";
}</PRE>
<P>The <A HREF="../../lib/Pod/perlfunc.html#item_fork"><CODE>fork()</CODE></A> has to come before the <CODE>setsid()</CODE> to ensure that you aren't a
process group leader (the <CODE>setsid()</CODE> will fail if you are). If your
system doesn't have the <CODE>setsid()</CODE> function, open <EM>/dev/tty</EM> and use the
<CODE>TIOCNOTTY</CODE> <A HREF="../../lib/Pod/perlfunc.html#item_ioctl"><CODE>ioctl()</CODE></A> on it instead. See <EM>tty(4)</EM> for details.</P>
<P>Non-Unix users should check their Your_OS::Process module for other
<P>Another interesting approach to IPC is making your single program go
multiprocess and communicate between (or even amongst) yourselves. The
<A HREF="../../lib/Pod/perlfunc.html#item_open"><CODE>open()</CODE></A> function will accept a file argument of either <CODE>"-|"</CODE> or <CODE>"|-"</CODE>
to do a very interesting thing: it forks a child connected to the
filehandle you've opened. The child is running the same program as the
parent. This is useful for safely opening a file when running under an
assumed UID or GID, for example. If you open a pipe <EM>to</EM> minus, you can
write to the filehandle you opened and your kid will find it in his
STDIN. If you open a pipe <EM>from</EM> minus, you can read from the filehandle
you opened whatever your kid writes to his STDOUT.</P>
<PRE>
use English;
my $sleep_count = 0;</PRE>
<PRE>
do {
$pid = open(KID_TO_WRITE, "|-");
unless (defined $pid) {
warn "cannot fork: $!";
die "bailing out" if $sleep_count++ > 6;
sleep 10;
}
} until defined $pid;</PRE>
<PRE>
if ($pid) { # parent
print KID_TO_WRITE @some_data;
close(KID_TO_WRITE) || warn "kid exited $?";
} else { # child
($EUID, $EGID) = ($UID, $GID); # suid progs only
open (FILE, "> /safe/file")
|| die "can't open /safe/file: $!";
while (<STDIN>) {
print FILE; # child's STDIN is parent's KID
}
exit; # don't forget this
}</PRE>
<P>Another common use for this construct is when you need to execute
something without the shell's interference. With system(), it's
straightforward, but you can't use a pipe open or backticks safely.
That's because there's no way to stop the shell from getting its hands on
your arguments. Instead, use lower-level control to call <A HREF="../../lib/Pod/perlfunc.html#item_exec"><CODE>exec()</CODE></A> directly.</P>
<P>Here's a safe backtick or pipe open for read:</P>
<PRE>
# add error processing as above
$pid = open(KID_TO_READ, "-|");</PRE>
<PRE>
if ($pid) { # parent
while (<KID_TO_READ>) {
# do something interesting
}
close(KID_TO_READ) || warn "kid exited $?";</PRE>
<PRE>
} else { # child
($EUID, $EGID) = ($UID, $GID); # suid only
exec($program, @options, @args)
|| die "can't exec program: $!";
# NOTREACHED
}</PRE>
<P>And here's a safe pipe open for writing:</P>
<PRE>
# add error processing as above
$pid = open(KID_TO_WRITE, "|-");
$SIG{ALRM} = sub { die "whoops, $program pipe broke" };</PRE>
<P>Note that these operations are full Unix forks, which means they may not be
correctly implemented on alien systems. Additionally, these are not true
multithreading. If you'd like to learn more about threading, see the
<EM>modules</EM> file mentioned below in the SEE ALSO section.</P>
<P>
<H2><A NAME="bidirectional communication with another process">Bidirectional Communication with Another Process</A></H2>
<P>While this works reasonably well for unidirectional communication, what
about bidirectional communication? The obvious thing you'd like to do
doesn't actually work:</P>
<PRE>
open(PROG_FOR_READING_AND_WRITING, "| some program |")</PRE>
<P>and if you forget to use the <CODE>use warnings</CODE> pragma or the <STRONG>-w</STRONG> flag,
then you'll miss out entirely on the diagnostic message:</P>
<PRE>
Can't do bidirectional pipe at -e line 1.</PRE>
<P>If you really want to, you can use the standard <CODE>open2()</CODE> library function
to catch both ends. There's also an <CODE>open3()</CODE> for tridirectional I/O so you
can also catch your child's STDERR, but doing so would then require an
awkward <A HREF="../../lib/Pod/perlfunc.html#item_select"><CODE>select()</CODE></A> loop and wouldn't allow you to use normal Perl input
operations.</P>
<P>If you look at its source, you'll see that <CODE>open2()</CODE> uses low-level
primitives like Unix <A HREF="../../lib/Pod/perlfunc.html#item_pipe"><CODE>pipe()</CODE></A> and <A HREF="../../lib/Pod/perlfunc.html#item_exec"><CODE>exec()</CODE></A> calls to create all the connections.
While it might have been slightly more efficient by using socketpair(), it
would have then been even less portable than it already is. The <CODE>open2()</CODE>
and <CODE>open3()</CODE> functions are unlikely to work anywhere except on a Unix
system or some other one purporting to be POSIX compliant.</P>
<P>Here's an example of using open2():</P>
<PRE>
use FileHandle;
use IPC::Open2;
$pid = open2(*Reader, *Writer, "cat -u -n" );
print Writer "stuff\n";
$got = <Reader>;</PRE>
<P>The problem with this is that Unix buffering is really going to
ruin your day. Even though your <CODE>Writer</CODE> filehandle is auto-flushed,
and the process on the other end will get your data in a timely manner,
you can't usually do anything to force it to give it back to you
in a similarly quick fashion. In this case, we could, because we
gave <EM>cat</EM> a <STRONG>-u</STRONG> flag to make it unbuffered. But very few Unix
commands are designed to operate over pipes, so this seldom works
unless you yourself wrote the program on the other end of the
double-ended pipe.</P>
<P>A solution to this is the nonstandard <EM>Comm.pl</EM> library. It uses
pseudo-ttys to make your program behave more reasonably:</P>
<PRE>
require 'Comm.pl';
$ph = open_proc('cat -n');
for (1..10) {
print $ph "a line\n";
print "got back ", scalar <$ph>;
}</PRE>
<P>This way you don't have to have control over the source code of the
program you're using. The <EM>Comm</EM> library also has <CODE>expect()</CODE>
and <CODE>interact()</CODE> functions. Find the library (and we hope its
successor <EM>IPC::Chat</EM>) at your nearest CPAN archive as detailed
in the SEE ALSO section below.</P>
<P>The newer Expect.pm module from CPAN also addresses this kind of thing.
This module requires two other modules from CPAN: IO::Pty and IO::Stty.
It sets up a pseudo-terminal to interact with programs that insist on
using talking to the terminal device driver. If your system is
amongst those supported, this may be your best bet.</P>
<P>
<H2><A NAME="bidirectional communication with yourself">Bidirectional Communication with Yourself</A></H2>
<P>If you want, you may make low-level <A HREF="../../lib/Pod/perlfunc.html#item_pipe"><CODE>pipe()</CODE></A> and <A HREF="../../lib/Pod/perlfunc.html#item_fork"><CODE>fork()</CODE></A>
to stitch this together by hand. This example only
talks to itself, but you could reopen the appropriate
handles to STDIN and STDOUT and call other processes.</P>
<PRE>
#!/usr/bin/perl -w
# pipe1 - bidirectional communication using two pipe pairs
# designed for the socketpair-challenged
use IO::Handle; # thousands of lines just for autoflush :-(
pipe(PARENT_RDR, CHILD_WTR); # XXX: failure?
pipe(CHILD_RDR, PARENT_WTR); # XXX: failure?
CHILD_WTR->autoflush(1);
PARENT_WTR->autoflush(1);</PRE>
<PRE>
if ($pid = fork) {
close PARENT_RDR; close PARENT_WTR;
print CHILD_WTR "Parent Pid $$ is sending this\n";
chomp($line = <CHILD_RDR>);
print "Parent Pid $$ just read this: `$line'\n";
close CHILD_RDR; close CHILD_WTR;
waitpid($pid,0);
} else {
die "cannot fork: $!" unless defined $pid;
close CHILD_RDR; close CHILD_WTR;
chomp($line = <PARENT_RDR>);
print "Child Pid $$ just read this: `$line'\n";
print PARENT_WTR "Child Pid $$ is sending this\n";
close PARENT_RDR; close PARENT_WTR;
exit;
}</PRE>
<P>But you don't actually have to make two pipe calls. If you
have the <A HREF="../../lib/Pod/perlfunc.html#item_socketpair"><CODE>socketpair()</CODE></A> system call, it will do this all for you.</P>
<PRE>
#!/usr/bin/perl -w
# pipe2 - bidirectional communication using socketpair
# "the best ones always go both ways"</PRE>
<PRE>
use Socket;
use IO::Handle; # thousands of lines just for autoflush :-(
# We say AF_UNIX because although *_LOCAL is the
# POSIX 1003.1g form of the constant, many machines
