[ViewVC] Diff of: cvs/AnyEvent-Fork/Fork.pm

Comparing AnyEvent-Fork/Fork.pm (file contents):
Revision 1.35 by root, Sat Apr 6 09:39:12 2013 UTC vs.
Revision 1.41 by root, Mon Apr 8 03:20:53 2013 UTC

 Special care has been taken to make this module useful from other modules,
 while still supporting specialised environments such as L<App::Staticperl>
 or L<PAR::Packer>.
-=head1 WHAT THIS MODULE IS NOT
+=head2 WHAT THIS MODULE IS NOT
 This module only creates processes and lets you pass file handles and
 strings to it, and run perl code. It does not implement any kind of RPC -
 there is no back channel from the process back to you, and there is no RPC
 or message passing going on.
 in whatever way you like, use some message-passing module such
 as L<AnyEvent::MP>, some pipe such as L<AnyEvent::ZeroMQ>, use
 L<AnyEvent::Handle> on both sides to send e.g. JSON or Storable messages,
 and so on.
+=head2 COMPARISON TO OTHER MODULES
+There is an abundance of modules on CPAN that do "something fork", such as
+L<Parallel::ForkManager>, L<AnyEvent::ForkManager>, L<AnyEvent::Worker>
+or L<AnyEvent::Subprocess>. There are modules that implement their own
+process management, such as L<AnyEvent::DBI>.
+The problems that all these modules try to solve are real, however, none
+of them (from what I have seen) tackle the very real problems of unwanted
+memory sharing, efficiency, not being able to use event processing or
+similar modules in the processes they create.
+This module doesn't try to replace any of them - instead it tries to solve
+the problem of creating processes with a minimum of fuss and overhead (and
+also luxury). Ideally, most of these would use AnyEvent::Fork internally,
+except they were written before AnyEvent:Fork was available, so obviously
+had to roll their own.
-=head1 PROBLEM STATEMENT
+=head2 PROBLEM STATEMENT
 There are two traditional ways to implement parallel processing on UNIX
 like operating systems - fork and process, and fork+exec and process. They
 have different advantages and disadvantages that I describe below,
 together with how this module tries to mitigate the disadvantages.
    open my $output, ">/tmp/log" or die "$!";
    AnyEvent::Fork
       ->new
       ->eval ('
+           # compile a helper function for later use
            sub run {
               my ($fh, $output, @cmd) = @_;
               # perl will clear close-on-exec on STDOUT/STDERR
               open STDOUT, ">&", $output or die;
 use AnyEvent;
 use AnyEvent::Util ();
 use IO::FDPass;
-our $VERSION = 0.5;
+our $VERSION = 0.6;
-our $PERL; # the path to the perl interpreter, deduces with various forms of magic
 =over 4
 =back
    if ($pid eq 0) {
       require AnyEvent::Fork::Serve;
       $AnyEvent::Fork::Serve::OWNER = $parent;
       close $fh;
       $0 = "$_[1] of $parent";
-      $SIG{CHLD} = 'IGNORE';
       AnyEvent::Fork::Serve::serve ($slave);
       exit 0;
    } elsif (!$pid) {
       die "AnyEvent::Fork::Early/Template: unable to fork template process: $!";
    }
     479 vfork+execs per second, using AnyEvent::Fork->new_exec
 So how can C<< AnyEvent->new >> be faster than a standard fork, even
 though it uses the same operations, but adds a lot of overhead?
-The difference is simply the process size: forking the 6MB process takes
+The difference is simply the process size: forking the 5MB process takes
-so much longer than forking the 2.5MB template process that the overhead
+so much longer than forking the 2.5MB template process that the extra
-introduced is canceled out.
+overhead introduced is canceled out.
 If the benchmark process grows, the normal fork becomes even slower:
-   1340 new processes, manual fork in a 20MB process
+   1340 new processes, manual fork of a 20MB process
-    731 new processes, manual fork in a 200MB process
+    731 new processes, manual fork of a 200MB process
-    235 new processes, manual fork in a 2000MB process
+    235 new processes, manual fork of a 2000MB process
-What that means (to me) is that I can use this module without having a
+What that means (to me) is that I can use this module without having a bad
-very bad conscience because of the extra overhead required to start new
+conscience because of the extra overhead required to start new processes.
-processes.
 =head1 TYPICAL PROBLEMS
 This section lists typical problems that remain. I hope by recognising
 them, most can be avoided.
 =over 4
-=item "leaked" file descriptors for exec'ed processes
+=item leaked file descriptors for exec'ed processes
 POSIX systems inherit file descriptors by default when exec'ing a new
 process. While perl itself laudably sets the close-on-exec flags on new
 file handles, most C libraries don't care, and even if all cared, it's
 often not possible to set the flag in a race-free manner.
 libraries or the code that leaks those file descriptors.
 Fortunately, most of these leaked descriptors do no harm, other than
 sitting on some resources.
-=item "leaked" file descriptors for fork'ed processes
+=item leaked file descriptors for fork'ed processes
 Normally, L<AnyEvent::Fork> does start new processes by exec'ing them,
 which closes file descriptors not marked for being inherited.
 However, L<AnyEvent::Fork::Early> and L<AnyEvent::Fork::Template> offer
 The solution is to either not load these modules before use'ing
 L<AnyEvent::Fork::Early> or L<AnyEvent::Fork::Template>, or to delay
 initialising them, for example, by calling C<init Gtk2> manually.
-=item exit runs destructors
+=item exiting calls object destructors
-This only applies to users of Lc<AnyEvent::Fork:Early> and
+This only applies to users of L<AnyEvent::Fork:Early> and
-L<AnyEvent::Fork::Template>.
+L<AnyEvent::Fork::Template>, or when initialiasing code creates objects
+that reference external resources.
 When a process created by AnyEvent::Fork exits, it might do so by calling
 exit, or simply letting perl reach the end of the program. At which point
 Perl runs all destructors.
 to make it so, mostly due to the bloody broken perl that nobody seems to
 care about. The fork emulation is a bad joke - I have yet to see something
 useful that you can do with it without running into memory corruption
 issues or other braindamage. Hrrrr.
-Cygwin perl is not supported at the moment, as it should implement fd
+Cygwin perl is not supported at the moment due to some hilarious
-passing, but doesn't, and rolling my own is hard, as cygwin doesn't
+shortcomings of its API - see L<IO::FDPoll> for more details.
-support enough functionality to do it.
 =head1 SEE ALSO
 L<AnyEvent::Fork::Early> (to avoid executing a perl interpreter),
 L<AnyEvent::Fork::Template> (to create a process by forking the main

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent-Fork/Fork.pm (file contents): Revision 1.35 by root, Sat Apr 6 09:39:12 2013 UTC vs. Revision 1.41 by root, Mon Apr 8 03:20:53 2013 UTC

Diff Legend

Comparing AnyEvent-Fork/Fork.pm (file contents):
Revision 1.35 by root, Sat Apr 6 09:39:12 2013 UTC vs.
Revision 1.41 by root, Mon Apr 8 03:20:53 2013 UTC