X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlfork.pod;h=48d65ed4c589659180468c99b3a1bd6c98f4f33a;hb=c1effa61278e47c916466883d74905b04fedc388;hp=dc0a82bfd6423dc73477c84988e3707d87468031;hpb=c7fa416ba7ee901b0af8471f9c36407d36d3b1bc;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlfork.pod b/pod/perlfork.pod
index dc0a82b..48d65ed 100644
--- a/pod/perlfork.pod
+++ b/pod/perlfork.pod
@@ -1,13 +1,13 @@
 =head1 NAME
 
-perlfork - Perl's fork() emulation (EXPERIMENTAL, subject to change)
+perlfork - Perl's fork() emulation
 
 =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.
+    NOTE:  As of the 5.8.0 release, fork() emulation has considerably
+    matured.  However, there are still a few known bugs and differences
+    from real fork() that might affect you.  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
@@ -95,12 +95,15 @@ manipulation functions applied to the ID returned by fork() will affect the
 waiting pseudo-process that called exec(), not the real process it is
 waiting for after the exec().
 
+When exec() is called inside a pseudo-process then DESTROY methods and
+END blocks will still be called after the external process returns.
+
 =item exit()
 
 exit() always exits just the executing pseudo-process, after automatically
 wait()-ing for any outstanding child pseudo-processes.  Note that this means
 that the process as a whole will not exit unless all running pseudo-processes
-have exited.
+have exited.  See below for some limitations with open filehandles.
 
 =item Open handles to files, directories and network sockets
 
@@ -177,6 +180,13 @@ the seek position in the parent will change it in the child and vice-versa.
 One can avoid this by opening files that need distinct seek pointers
 separately in the child.
 
+On some operating systems, notably Solaris and Unixware, calling C<exit()>
+from a child process will flush and close open filehandles in the parent,
+thereby corrupting the filehandles.  On these systems, calling C<_exit()>
+is suggested instead.  C<_exit()> is available in Perl through the 
+C<POSIX> module.  Please consult your systems manpages for more information
+on this.
+
 =item Forking pipe open() not yet implemented
 
 The C<open(FOO, "|-")> and C<open(BAR, "-|")> constructs are not yet
@@ -208,7 +218,6 @@ write to a forked child:
     else {
 	# child
 	while (<STDIN>) { print; }
-	close STDIN;
 	exit(0);
     }
 
@@ -238,7 +247,6 @@ And this one reads from the child:
     else {
 	# child
 	print "pipe_from_fork\n";
-	close STDOUT;
 	exit(0);
     }
 
@@ -279,17 +287,6 @@ are expected to be fixed for thread-safety.
 
 =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
@@ -298,6 +295,15 @@ representation for pseudo-process IDs will be implemented in future.
 
 =item *
 
+In certain cases, the OS-level handles created by the pipe(), socket(),
+and accept() operators are apparently not duplicated accurately in
+pseudo-processes.  This only happens in some situations, but where it
+does happen, it may result in deadlocks between the read and write ends
+of pipe handles, or inability to send or receive data across socket
+handles.
+
+=item *
+
 This document may be incomplete in some respects.
 
 =back