pod/perlfork.pod

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