[ Index ]

PHP Cross Reference of Unnamed Project




/se3-unattended/var/se3/unattended/install/linuxaux/opt/perl/lib/5.10.0/pod/ -> perlfork.pod (source)

   1  =head1 NAME
   3  perlfork - Perl's fork() emulation
   5  =head1 SYNOPSIS
   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.
  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.
  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.
  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.
  29  =head1 DESCRIPTION
  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.
  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.
  44  =head2 Behavior of other Perl features in forked pseudo-processes
  46  Most Perl features behave in a natural way within pseudo-processes.
  48  =over 8
  50  =item $$ or $PROCESS_ID
  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.
  57  =item %ENV
  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.
  64  =item chdir() and all other builtins that accept filenames
  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.
  72  =item wait() and waitpid()
  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.
  78  =item kill()
  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.
  87  =item exec()
  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().
  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.
 101  =item exit()
 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.
 108  =item Open handles to files, directories and network sockets
 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.
 114  =back
 116  =head2 Resource limits
 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.
 126  =head2 Killing the parent process
 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.
 132  =head2 Lifetime of the parent process and pseudo-processes
 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.
 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.
 146  =over 8
 148  =item BEGIN blocks
 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:
 155      BEGIN {
 156          fork and exit;        # fork child and exit the parent
 157      print "inner\n";
 158      }
 159      print "outer\n";
 161  This will print:
 163      inner
 165  rather than the expected:
 167      inner
 168      outer
 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.
 174  =item Open filehandles
 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.
 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.
 190  =item Forking pipe open() not yet implemented
 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:
 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      }
 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      }
 224  And this one reads from the child:
 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      }
 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      }
 253  Forking pipe open() constructs will be supported in future.
 255  =item Global state maintained by XSUBs 
 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.
 265  =item Interpreter embedded in larger application
 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.
 274  =item Thread-safety of extensions
 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.
 282  =back
 284  =head1 BUGS
 286  =over 8
 288  =item *
 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.
 296  =item *
 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.
 305  =item *
 307  This document may be incomplete in some respects.
 309  =back
 311  =head1 AUTHOR
 313  Support for concurrent interpreters and the fork() emulation was implemented
 314  by ActiveState, with funding from Microsoft Corporation.
 316  This document is authored and maintained by Gurusamy Sarathy
 317  E<lt>gsar@activestate.comE<gt>.
 319  =head1 SEE ALSO
 321  L<perlfunc/"fork">, L<perlipc>
 323  =cut

Generated: Tue Mar 17 22:47:18 2015 Cross-referenced by PHPXref 0.7.1