summaryrefslogtreecommitdiff
path: root/Master/tlpkg/tlperl/lib/pods/perlfork.pod
diff options
context:
space:
mode:
Diffstat (limited to 'Master/tlpkg/tlperl/lib/pods/perlfork.pod')
-rw-r--r--Master/tlpkg/tlperl/lib/pods/perlfork.pod357
1 files changed, 0 insertions, 357 deletions
diff --git a/Master/tlpkg/tlperl/lib/pods/perlfork.pod b/Master/tlpkg/tlperl/lib/pods/perlfork.pod
deleted file mode 100644
index 7729444c40b..00000000000
--- a/Master/tlpkg/tlperl/lib/pods/perlfork.pod
+++ /dev/null
@@ -1,357 +0,0 @@
-=head1 NAME
-
-perlfork - Perl's fork() emulation
-
-=head1 SYNOPSIS
-
- 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
-call is available, Perl's fork() simply calls it.
-
-On some platforms such as Windows where the fork() system call is not
-available, Perl can be built to emulate fork() at the interpreter level.
-While the emulation is designed to be as compatible as possible with the
-real fork() at the level of the Perl program, there are certain
-important differences that stem from the fact that all the pseudo child
-"processes" created this way live in the same real process as far as the
-operating system is concerned.
-
-This document provides a general overview of the capabilities and
-limitations of the fork() emulation. Note that the issues discussed here
-are not applicable to platforms where a real fork() is available and Perl
-has been configured to use it.
-
-=head1 DESCRIPTION
-
-The fork() emulation is implemented at the level of the Perl interpreter.
-What this means in general is that running fork() will actually clone the
-running interpreter and all its state, and run the cloned interpreter in
-a separate thread, beginning execution in the new thread just after the
-point where the fork() was called in the parent. We will refer to the
-thread that implements this child "process" as the pseudo-process.
-
-To the Perl program that called fork(), all this is designed to be
-transparent. The parent returns from the fork() with a pseudo-process
-ID that can be subsequently used in any process-manipulation functions;
-the child returns from the fork() with a value of C<0> to signify that
-it is the child pseudo-process.
-
-=head2 Behavior of other Perl features in forked pseudo-processes
-
-Most Perl features behave in a natural way within pseudo-processes.
-
-=over 8
-
-=item $$ or $PROCESS_ID
-
-This special variable is correctly set to the pseudo-process ID.
-It can be used to identify pseudo-processes within a particular
-session. Note that this value is subject to recycling if any
-pseudo-processes are launched after others have been wait()-ed on.
-
-=item %ENV
-
-Each pseudo-process maintains its own virtual environment. Modifications
-to %ENV affect the virtual environment, and are only visible within that
-pseudo-process, and in any processes (or pseudo-processes) launched from
-it.
-
-=item chdir() and all other builtins that accept filenames
-
-Each pseudo-process maintains its own virtual idea of the current directory.
-Modifications to the current directory using chdir() are only visible within
-that pseudo-process, and in any processes (or pseudo-processes) launched from
-it. All file and directory accesses from the pseudo-process will correctly
-map the virtual working directory to the real working directory appropriately.
-
-=item wait() and waitpid()
-
-wait() and waitpid() can be passed a pseudo-process ID returned by fork().
-These calls will properly wait for the termination of the pseudo-process
-and return its status.
-
-=item kill()
-
-C<kill('KILL', ...)> can be used to terminate a pseudo-process by
-passing it the ID returned by fork(). The outcome of kill on a pseudo-process
-is unpredictable and it should not be used except
-under dire circumstances, because the operating system may not
-guarantee integrity of the process resources when a running thread is
-terminated. The process which implements the pseudo-processes can be blocked
-and the Perl interpreter hangs. Note that using C<kill('KILL', ...)> on a
-pseudo-process() may typically cause memory leaks, because the thread
-that implements the pseudo-process does not get a chance to clean up
-its resources.
-
-C<kill('TERM', ...)> can also be used on pseudo-processes, but the
-signal will not be delivered while the pseudo-process is blocked by a
-system call, e.g. waiting for a socket to connect, or trying to read
-from a socket with no data available. Starting in Perl 5.14 the
-parent process will not wait for children to exit once they have been
-signalled with C<kill('TERM', ...)> to avoid deadlock during process
-exit. You will have to explicitly call waitpid() to make sure the
-child has time to clean-up itself, but you are then also responsible
-that the child is not blocking on I/O either.
-
-=item exec()
-
-Calling exec() within a pseudo-process actually spawns the requested
-executable in a separate process and waits for it to complete before
-exiting with the same exit status as that process. This means that the
-process ID reported within the running executable will be different from
-what the earlier Perl fork() might have returned. Similarly, any process
-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. See below for some limitations with open filehandles.
-
-=item Open handles to files, directories and network sockets
-
-All open handles are dup()-ed in pseudo-processes, so that closing
-any handles in one process does not affect the others. See below for
-some limitations.
-
-=back
-
-=head2 Resource limits
-
-In the eyes of the operating system, pseudo-processes created via the fork()
-emulation are simply threads in the same process. This means that any
-process-level limits imposed by the operating system apply to all
-pseudo-processes taken together. This includes any limits imposed by the
-operating system on the number of open file, directory and socket handles,
-limits on disk space usage, limits on memory size, limits on CPU utilization
-etc.
-
-=head2 Killing the parent process
-
-If the parent process is killed (either using Perl's kill() builtin, or
-using some external means) all the pseudo-processes are killed as well,
-and the whole process exits.
-
-=head2 Lifetime of the parent process and pseudo-processes
-
-During the normal course of events, the parent process and every
-pseudo-process started by it will wait for their respective pseudo-children
-to complete before they exit. This means that the parent and every
-pseudo-child created by it that is also a pseudo-parent will only exit
-after their pseudo-children have exited.
-
-Starting with Perl 5.14 a parent will not wait() automatically
-for any child that has been signalled with C<sig('TERM', ...)>
-to avoid a deadlock in case the child is blocking on I/O and
-never receives the signal.
-
-=head1 CAVEATS AND LIMITATIONS
-
-=over 8
-
-=item BEGIN blocks
-
-The fork() emulation will not work entirely correctly when called from
-within a BEGIN block. The forked copy will run the contents of the
-BEGIN block, but will not continue parsing the source stream after the
-BEGIN block. For example, consider the following code:
-
- BEGIN {
- fork and exit; # fork child and exit the parent
- print "inner\n";
- }
- print "outer\n";
-
-This will print:
-
- inner
-
-rather than the expected:
-
- inner
- outer
-
-This limitation arises from fundamental technical difficulties in
-cloning and restarting the stacks used by the Perl parser in the
-middle of a parse.
-
-=item Open filehandles
-
-Any filehandles open at the time of the fork() will be dup()-ed. Thus,
-the files can be closed independently in the parent and child, but beware
-that the dup()-ed handles will still share the same seek pointer. Changing
-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 system's manpages for more information
-on this.
-
-=item Open directory handles
-
-Perl will completely read from all open directory handles until they
-reach the end of the stream. It will then seekdir() back to the
-original location and all future readdir() requests will be fulfilled
-from the cache buffer. That means that neither the directory handle held
-by the parent process nor the one held by the child process will see
-any changes made to the directory after the fork() call.
-
-Note that rewinddir() has a similar limitation on Windows and will not
-force readdir() to read the directory again either. Only a newly
-opened directory handle will reflect changes to the directory.
-
-=item Forking pipe open() not yet implemented
-
-The C<open(FOO, "|-")> and C<open(BAR, "-|")> constructs are not yet
-implemented. This limitation can be easily worked around in new code
-by creating a pipe explicitly. The following example shows how to
-write to a forked child:
-
- # simulate open(FOO, "|-")
- sub pipe_to_fork ($) {
- my $parent = shift;
- pipe my $child, $parent or die;
- my $pid = fork();
- die "fork() failed: $!" unless defined $pid;
- if ($pid) {
- close $child;
- }
- else {
- close $parent;
- open(STDIN, "<&=" . fileno($child)) or die;
- }
- $pid;
- }
-
- if (pipe_to_fork('FOO')) {
- # parent
- print FOO "pipe_to_fork\n";
- close FOO;
- }
- else {
- # child
- while (<STDIN>) { print; }
- exit(0);
- }
-
-And this one reads from the child:
-
- # simulate open(FOO, "-|")
- sub pipe_from_fork ($) {
- my $parent = shift;
- pipe $parent, my $child or die;
- my $pid = fork();
- die "fork() failed: $!" unless defined $pid;
- if ($pid) {
- close $child;
- }
- else {
- close $parent;
- open(STDOUT, ">&=" . fileno($child)) or die;
- }
- $pid;
- }
-
- if (pipe_from_fork('BAR')) {
- # parent
- while (<BAR>) { print; }
- close BAR;
- }
- else {
- # child
- print "pipe_from_fork\n";
- exit(0);
- }
-
-Forking pipe open() constructs will be supported in future.
-
-=item Global state maintained by XSUBs
-
-External subroutines (XSUBs) that maintain their own global state may
-not work correctly. Such XSUBs will either need to maintain locks to
-protect simultaneous access to global data from different pseudo-processes,
-or maintain all their state on the Perl symbol table, which is copied
-naturally when fork() is called. A callback mechanism that provides
-extensions an opportunity to clone their state will be provided in the
-near future.
-
-=item Interpreter embedded in larger application
-
-The fork() emulation may not behave as expected when it is executed in an
-application which embeds a Perl interpreter and calls Perl APIs that can
-evaluate bits of Perl code. This stems from the fact that the emulation
-only has knowledge about the Perl interpreter's own data structures and
-knows nothing about the containing application's state. For example, any
-state carried on the application's own call stack is out of reach.
-
-=item Thread-safety of extensions
-
-Since the fork() emulation runs code in multiple threads, extensions
-calling into non-thread-safe libraries may not work reliably when
-calling fork(). As Perl's threading support gradually becomes more
-widely adopted even on platforms with a native fork(), such extensions
-are expected to be fixed for thread-safety.
-
-=back
-
-=head1 PORTABILITY CAVEATS
-
-In portable Perl code, C<kill(9, $child)> must not be used on forked processes.
-Killing a forked process is unsafe and has unpredictable results.
-See L</kill()>, above.
-
-=head1 BUGS
-
-=over 8
-
-=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
-the system never allocates a thread ID of C<1> for user threads. A better
-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
-
-=head1 AUTHOR
-
-Support for concurrent interpreters and the fork() emulation was implemented
-by ActiveState, with funding from Microsoft Corporation.
-
-This document is authored and maintained by Gurusamy Sarathy
-E<lt>gsar@activestate.comE<gt>.
-
-=head1 SEE ALSO
-
-L<perlfunc/"fork">, L<perlipc>
-
-=cut