home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / perl560.zip / pod / perlfork.pod < prev    next >
Text File  |  2000-01-27  |  10KB  |  302 lines

  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
  302.