[Summary view] [Print] [Text view]

   1  =head1 NAME
   2  
   3  perlfork - Perl's fork() emulation
   4  
   5  =head1 SYNOPSIS
   6  
   7      NOTE:  As of the 5.8.0 release, fork() emulation has considerably
   8      matured.  However, there are still a few known bugs and differences
   9      from real fork() that might affect you.  See the "BUGS" and
  10      "CAVEATS AND LIMITATIONS" sections below.
  11  
  12  Perl provides a fork() keyword that corresponds to the Unix system call
  13  of the same name.  On most Unix-like platforms where the fork() system
  14  call is available, Perl's fork() simply calls it.
  15  
  16  On some platforms such as Windows where the fork() system call is not
  17  available, Perl can be built to emulate fork() at the interpreter level.
  18  While the emulation is designed to be as compatible as possible with the
  19  real fork() at the level of the Perl program, there are certain
  20  important differences that stem from the fact that all the pseudo child
  21  "processes" created this way live in the same real process as far as the
  22  operating system is concerned.
  23  
  24  This document provides a general overview of the capabilities and
  25  limitations of the fork() emulation.  Note that the issues discussed here
  26  are not applicable to platforms where a real fork() is available and Perl
  27  has been configured to use it.
  28  
  29  =head1 DESCRIPTION
  30  
  31  The fork() emulation is implemented at the level of the Perl interpreter.
  32  What this means in general is that running fork() will actually clone the
  33  running interpreter and all its state, and run the cloned interpreter in
  34  a separate thread, beginning execution in the new thread just after the
  35  point where the fork() was called in the parent.  We will refer to the
  36  thread that implements this child "process" as the pseudo-process.
  37  
  38  To the Perl program that called fork(), all this is designed to be
  39  transparent.  The parent returns from the fork() with a pseudo-process
  40  ID that can be subsequently used in any process manipulation functions;
  41  the child returns from the fork() with a value of C<0> to signify that
  42  it is the child pseudo-process.
  43  
  44  =head2 Behavior of other Perl features in forked pseudo-processes
  45  
  46  Most Perl features behave in a natural way within pseudo-processes.
  47  
  48  =over 8
  49  
  50  =item $$ or $PROCESS_ID
  51  
  52  This special variable is correctly set to the pseudo-process ID.
  53  It can be used to identify pseudo-processes within a particular
  54  session.  Note that this value is subject to recycling if any
  55  pseudo-processes are launched after others have been wait()-ed on.
  56  
  57  =item %ENV
  58  
  59  Each pseudo-process maintains its own virtual environment.  Modifications
  60  to %ENV affect the virtual environment, and are only visible within that
  61  pseudo-process, and in any processes (or pseudo-processes) launched from
  62  it.
  63  
  64  =item chdir() and all other builtins that accept filenames
  65  
  66  Each pseudo-process maintains its own virtual idea of the current directory.
  67  Modifications to the current directory using chdir() are only visible within
  68  that pseudo-process, and in any processes (or pseudo-processes) launched from
  69  it.  All file and directory accesses from the pseudo-process will correctly
  70  map the virtual working directory to the real working directory appropriately.
  71  
  72  =item wait() and waitpid()
  73  
  74  wait() and waitpid() can be passed a pseudo-process ID returned by fork().
  75  These calls will properly wait for the termination of the pseudo-process
  76  and return its status.
  77  
  78  =item kill()
  79  
  80  kill() can be used to terminate a pseudo-process by passing it the ID returned
  81  by fork().  This should not be used except under dire circumstances, because
  82  the operating system may not guarantee integrity of the process resources
  83  when a running thread is terminated.  Note that using kill() on a
  84  pseudo-process() may typically cause memory leaks, because the thread that
  85  implements the pseudo-process does not get a chance to clean up its resources.
  86  
  87  =item exec()
  88  
  89  Calling exec() within a pseudo-process actually spawns the requested
  90  executable in a separate process and waits for it to complete before
  91  exiting with the same exit status as that process.  This means that the
  92  process ID reported within the running executable will be different from
  93  what the earlier Perl fork() might have returned.  Similarly, any process
  94  manipulation functions applied to the ID returned by fork() will affect the
  95  waiting pseudo-process that called exec(), not the real process it is
  96  waiting for after the exec().
  97  
  98  When exec() is called inside a pseudo-process then DESTROY methods and
  99  END blocks will still be called after the external process returns.
 100  
 101  =item exit()
 102  
 103  exit() always exits just the executing pseudo-process, after automatically
 104  wait()-ing for any outstanding child pseudo-processes.  Note that this means
 105  that the process as a whole will not exit unless all running pseudo-processes
 106  have exited.  See below for some limitations with open filehandles.
 107  
 108  =item Open handles to files, directories and network sockets
 109  
 110  All open handles are dup()-ed in pseudo-processes, so that closing
 111  any handles in one process does not affect the others.  See below for
 112  some limitations.
 113  
 114  =back
 115  
 116  =head2 Resource limits
 117  
 118  In the eyes of the operating system, pseudo-processes created via the fork()
 119  emulation are simply threads in the same process.  This means that any
 120  process-level limits imposed by the operating system apply to all
 121  pseudo-processes taken together.  This includes any limits imposed by the
 122  operating system on the number of open file, directory and socket handles,
 123  limits on disk space usage, limits on memory size, limits on CPU utilization
 124  etc.
 125  
 126  =head2 Killing the parent process
 127  
 128  If the parent process is killed (either using Perl's kill() builtin, or
 129  using some external means) all the pseudo-processes are killed as well,
 130  and the whole process exits.
 131  
 132  =head2 Lifetime of the parent process and pseudo-processes
 133  
 134  During the normal course of events, the parent process and every
 135  pseudo-process started by it will wait for their respective pseudo-children
 136  to complete before they exit.  This means that the parent and every
 137  pseudo-child created by it that is also a pseudo-parent will only exit
 138  after their pseudo-children have exited.
 139  
 140  A way to mark a pseudo-processes as running detached from their parent (so
 141  that the parent would not have to wait() for them if it doesn't want to)
 142  will be provided in future.
 143  
 144  =head2 CAVEATS AND LIMITATIONS
 145  
 146  =over 8
 147  
 148  =item BEGIN blocks
 149  
 150  The fork() emulation will not work entirely correctly when called from
 151  within a BEGIN block.  The forked copy will run the contents of the
 152  BEGIN block, but will not continue parsing the source stream after the
 153  BEGIN block.  For example, consider the following code:
 154  
 155      BEGIN {
 156          fork and exit;        # fork child and exit the parent
 157      print "inner\n";
 158      }
 159      print "outer\n";
 160  
 161  This will print:
 162  
 163      inner
 164  
 165  rather than the expected:
 166  
 167      inner
 168      outer
 169  
 170  This limitation arises from fundamental technical difficulties in
 171  cloning and restarting the stacks used by the Perl parser in the
 172  middle of a parse.
 173  
 174  =item Open filehandles
 175  
 176  Any filehandles open at the time of the fork() will be dup()-ed.  Thus,
 177  the files can be closed independently in the parent and child, but beware
 178  that the dup()-ed handles will still share the same seek pointer.  Changing
 179  the seek position in the parent will change it in the child and vice-versa.
 180  One can avoid this by opening files that need distinct seek pointers
 181  separately in the child.
 182  
 183  On some operating systems, notably Solaris and Unixware, calling C<exit()>
 184  from a child process will flush and close open filehandles in the parent,
 185  thereby corrupting the filehandles.  On these systems, calling C<_exit()>
 186  is suggested instead.  C<_exit()> is available in Perl through the 
 187  C<POSIX> module.  Please consult your systems manpages for more information
 188  on this.
 189  
 190  =item Forking pipe open() not yet implemented
 191  
 192  The C<open(FOO, "|-")> and C<open(BAR, "-|")> constructs are not yet
 193  implemented.  This limitation can be easily worked around in new code
 194  by creating a pipe explicitly.  The following example shows how to
 195  write to a forked child:
 196  
 197      # simulate open(FOO, "|-")
 198      sub pipe_to_fork ($) {
 199      my $parent = shift;
 200      pipe my $child, $parent or die;
 201      my $pid = fork();
 202      die "fork() failed: $!" unless defined $pid;
 203      if ($pid) {
 204          close $child;
 205      }
 206      else {
 207          close $parent;
 208          open(STDIN, "<&=" . fileno($child)) or die;
 209      }
 210      $pid;
 211      }
 212  
 213      if (pipe_to_fork('FOO')) {
 214      # parent
 215      print FOO "pipe_to_fork\n";
 216      close FOO;
 217      }
 218      else {
 219      # child
 220      while (<STDIN>) { print; }
 221      exit(0);
 222      }
 223  
 224  And this one reads from the child:
 225  
 226      # simulate open(FOO, "-|")
 227      sub pipe_from_fork ($) {
 228      my $parent = shift;
 229      pipe $parent, my $child or die;
 230      my $pid = fork();
 231      die "fork() failed: $!" unless defined $pid;
 232      if ($pid) {
 233          close $child;
 234      }
 235      else {
 236          close $parent;
 237          open(STDOUT, ">&=" . fileno($child)) or die;
 238      }
 239      $pid;
 240      }
 241  
 242      if (pipe_from_fork('BAR')) {
 243      # parent
 244      while (<BAR>) { print; }
 245      close BAR;
 246      }
 247      else {
 248      # child
 249      print "pipe_from_fork\n";
 250      exit(0);
 251      }
 252  
 253  Forking pipe open() constructs will be supported in future.
 254  
 255  =item Global state maintained by XSUBs 
 256  
 257  External subroutines (XSUBs) that maintain their own global state may
 258  not work correctly.  Such XSUBs will either need to maintain locks to
 259  protect simultaneous access to global data from different pseudo-processes,
 260  or maintain all their state on the Perl symbol table, which is copied
 261  naturally when fork() is called.  A callback mechanism that provides
 262  extensions an opportunity to clone their state will be provided in the
 263  near future.
 264  
 265  =item Interpreter embedded in larger application
 266  
 267  The fork() emulation may not behave as expected when it is executed in an
 268  application which embeds a Perl interpreter and calls Perl APIs that can
 269  evaluate bits of Perl code.  This stems from the fact that the emulation
 270  only has knowledge about the Perl interpreter's own data structures and
 271  knows nothing about the containing application's state.  For example, any
 272  state carried on the application's own call stack is out of reach.
 273  
 274  =item Thread-safety of extensions
 275  
 276  Since the fork() emulation runs code in multiple threads, extensions
 277  calling into non-thread-safe libraries may not work reliably when
 278  calling fork().  As Perl's threading support gradually becomes more
 279  widely adopted even on platforms with a native fork(), such extensions
 280  are expected to be fixed for thread-safety.
 281  
 282  =back
 283  
 284  =head1 BUGS
 285  
 286  =over 8
 287  
 288  =item *
 289  
 290  Having pseudo-process IDs be negative integers breaks down for the integer
 291  C<-1> because the wait() and waitpid() functions treat this number as
 292  being special.  The tacit assumption in the current implementation is that
 293  the system never allocates a thread ID of C<1> for user threads.  A better
 294  representation for pseudo-process IDs will be implemented in future.
 295  
 296  =item *
 297  
 298  In certain cases, the OS-level handles created by the pipe(), socket(),
 299  and accept() operators are apparently not duplicated accurately in
 300  pseudo-processes.  This only happens in some situations, but where it
 301  does happen, it may result in deadlocks between the read and write ends
 302  of pipe handles, or inability to send or receive data across socket
 303  handles.
 304  
 305  =item *
 306  
 307  This document may be incomplete in some respects.
 308  
 309  =back
 310  
 311  =head1 AUTHOR
 312  
 313  Support for concurrent interpreters and the fork() emulation was implemented
 314  by ActiveState, with funding from Microsoft Corporation.
 315  
 316  This document is authored and maintained by Gurusamy Sarathy
 317  E<lt>gsar@activestate.comE<gt>.
 318  
 319  =head1 SEE ALSO
 320  
 321  L<perlfunc/"fork">, L<perlipc>
 322  
 323  =cut