=head1 NAME
-perlfork - Perl's fork() emulation
+perlfork - Perl's fork() emulation (EXPERIMENTAL, subject to change)
=head1 SYNOPSIS
+ WARNING: As of the 5.6.1 release, the fork() emulation continues
+ to be an experimental feature. Use in production applications is
+ not recommended. See the "BUGS" and "CAVEATS AND LIMITATIONS"
+ sections below.
+
Perl provides a fork() keyword that corresponds to the Unix system call
of the same name. On most Unix-like platforms where the fork() system
call is available, Perl's fork() simply calls it.
On some platforms such as Windows where the fork() system call is not
available, Perl can be built to emulate fork() at the interpreter level.
While the emulation is designed to be as compatible as possible with the
-real fork() at the the level of the Perl program, there are certain
+real fork() at the level of the Perl program, there are certain
important differences that stem from the fact that all the pseudo child
"processes" created this way live in the same real process as far as the
operating system is concerned.
=item %ENV
-Each pseudo-process maintains its own virtual enviroment. Modifications
+Each pseudo-process maintains its own virtual environment. Modifications
to %ENV affect the virtual environment, and are only visible within that
pseudo-process, and in any processes (or pseudo-processes) launched from
it.
One can avoid this by opening files that need distinct seek pointers
separately in the child.
+=item Forking pipe open() not yet implemented
+
+The C<open(FOO, "|-")> and C<open(BAR, "-|")> constructs are not yet
+implemented. This limitation can be easily worked around in new code
+by creating a pipe explicitly. The following example shows how to
+write to a forked child:
+
+ # simulate open(FOO, "|-")
+ sub pipe_to_fork ($) {
+ my $parent = shift;
+ pipe my $child, $parent or die;
+ my $pid = fork();
+ die "fork() failed: $!" unless defined $pid;
+ if ($pid) {
+ close $child;
+ }
+ else {
+ close $parent;
+ open(STDIN, "<&=" . fileno($child)) or die;
+ }
+ $pid;
+ }
+
+ if (pipe_to_fork('FOO')) {
+ # parent
+ print FOO "pipe_to_fork\n";
+ close FOO;
+ }
+ else {
+ # child
+ while (<STDIN>) { print; }
+ close STDIN;
+ exit(0);
+ }
+
+And this one reads from the child:
+
+ # simulate open(FOO, "-|")
+ sub pipe_from_fork ($) {
+ my $parent = shift;
+ pipe $parent, my $child or die;
+ my $pid = fork();
+ die "fork() failed: $!" unless defined $pid;
+ if ($pid) {
+ close $child;
+ }
+ else {
+ close $parent;
+ open(STDOUT, ">&=" . fileno($child)) or die;
+ }
+ $pid;
+ }
+
+ if (pipe_from_fork('BAR')) {
+ # parent
+ while (<BAR>) { print; }
+ close BAR;
+ }
+ else {
+ # child
+ print "pipe_from_fork\n";
+ close STDOUT;
+ exit(0);
+ }
+
+Forking pipe open() constructs will be supported in future.
+
=item Global state maintained by XSUBs
External subroutines (XSUBs) that maintain their own global state may
=item *
+Perl's regular expression engine currently does not play very nicely
+with the fork() emulation. There are known race conditions arising
+from the regular expression engine modifying state carried in the opcode
+tree at run time (the fork() emulation relies on the opcode tree being
+immutable). This typically happens when the regex contains paren groups
+or variables interpolated within it that force a run time recompilation
+of the regex. Due to this major bug, the fork() emulation is not
+recommended for use in production applications at this time.
+
+=item *
+
Having pseudo-process IDs be negative integers breaks down for the integer
C<-1> because the wait() and waitpid() functions treat this number as
being special. The tacit assumption in the current implementation is that