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

Comparing AnyEvent-Fork/Fork.pm (file contents):
Revision 1.59 by root, Fri Aug 30 12:06:48 2013 UTC vs.
Revision 1.63 by root, Wed Nov 26 13:36:18 2014 UTC

 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
+memory sharing, efficiency or not being able to use event processing, GUI
-similar modules in the processes they create.
+toolkits 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
 =item Forking usually creates a copy-on-write copy of the parent
 process.
 For example, modules or data files that are loaded will not use additional
-memory after a fork. When exec'ing a new process, modules and data files
+memory after a fork. Exec'ing a new process, in contrast, means modules
-might need to be loaded again, at extra CPU and memory cost. But when
+and data files might need to be loaded again, at extra CPU and memory
-forking, literally all data structures are copied - if the program frees
+cost.
+But when forking, you still create a copy of your data structures - if
-them and replaces them by new data, the child processes will retain the
+the program frees them and replaces them by new data, the child processes
-old version even if it isn't used, which can suddenly and unexpectedly
+will retain the old version even if it isn't used, which can suddenly and
-increase memory usage when freeing memory.
+unexpectedly increase memory usage when freeing memory.
+For example, L<Gtk2::CV> is an image viewer optimised for large
+directories (millions of pictures). It also forks subprocesses for
+thumbnail generation, which inherit the data structure that stores all
+file information. If the user changes the directory, it gets freed in
+the main process, leaving a copy in the thumbnailer processes. This can
+lead to many times the memory usage that would actually be required. The
+solution is to fork early (and being unable to dynamically generate more
+subprocesses or do this from a module)... or to use L<AnyEvent:Fork>.
-The trade-off is between more sharing with fork (which can be good or
+There is a trade-off between more sharing with fork (which can be good or
 bad), and no sharing with exec.
 This module allows the main program to do a controlled fork, and allows
 modules to exec processes safely at any time. When creating a custom
 process pool you can take advantage of data sharing via fork without
 shared and what isn't, at all times.
 =item Exec'ing a new perl process might be difficult.
 For example, it is not easy to find the correct path to the perl
-interpreter - C<$^X> might not be a perl interpreter at all.
+interpreter - C<$^X> might not be a perl interpreter at all. Worse, there
+might not even be a perl binary installed on the system.
 This module tries hard to identify the correct path to the perl
 interpreter. With a cooperative main program, exec'ing the interpreter
 might not even be necessary, but even without help from the main program,
 it will still work when used from a module.
 and modules are no longer loadable because they refer to a different
 perl version, or parts of a distribution are newer than the ones already
 loaded.
 This module supports creating pre-initialised perl processes to be used as
-a template for new processes.
+a template for new processes at a later time, e.g. for use in a process
+pool.
 =item Forking might be impossible when a program is running.
 For example, POSIX makes it almost impossible to fork from a
 multi-threaded program while doing anything useful in the child - in
 fact, if your perl program uses POSIX threads (even indirectly via
 e.g. L<IO::AIO> or L<threads>), you cannot call fork on the perl level
-anymore without risking corruption issues on a number of operating
+anymore without risking memory corruption or worse on a number of
-systems.
+operating systems.
 This module can safely fork helper processes at any time, by calling
 fork+exec in C, in a POSIX-compatible way (via L<Proc::FastSpawn>).
 =item Parallel processing with fork might be inconvenient or difficult
    my $stderr = $cv->recv;
 =head2 For stingy users: put the worker code into a C<DATA> section.
-When you want to be stingy with files, you cna put your code into the
+When you want to be stingy with files, you can put your code into the
 C<DATA> section of your module (or program):
    use AnyEvent::Fork;
    AnyEvent::Fork
 =head2 For stingy standalone programs: do not rely on external files at
 all.
 For single-file scripts it can be inconvenient to rely on external
-files - even when using < C<DATA> section, you still need to C<exec>
+files - even when using a C<DATA> section, you still need to C<exec> an
-an external perl interpreter, which might not be available when using
+external perl interpreter, which might not be available when using
 L<App::Staticperl>, L<Urlader> or L<PAR::Packer> for example.
 Two modules help here - L<AnyEvent::Fork::Early> forks a template process
 for all further calls to C<new_exec>, and L<AnyEvent::Fork::Template>
 forks the main program as a template process.
       my ($fh, @args) = @_;
       ...
    }
    # now preserve everything so far as AnyEvent::Fork object
-   # in §TEMPLATE.
+   # in $TEMPLATE.
    use AnyEvent::Fork::Template;
    # do not put code outside of BEGIN blocks until here
    # now use the $TEMPLATE process in any way you like
 use AnyEvent;
 use AnyEvent::Util ();
 use IO::FDPass;
-our $VERSION = 1.1;
+our $VERSION = 1.2;
 # the early fork template process
 our $EARLY;
 # the empty template process
    return $EARLY->fork
       if $EARLY;
    unless (defined $PERL) {
       # first find path of perl
-      my $perl = $;
+      my $perl = $^X;
       # first we try $^X, but the path must be absolute (always on win32), and end in sth.
       # that looks like perl. this obviously only works for posix and win32
       unless (
          ($^O eq "MSWin32" || $perl =~ m%^/%)
 Cygwin perl is not supported at the moment due to some hilarious
 shortcomings of its API - see L<IO::FDPoll> for more details. If you never
 use C<send_fh> and always use C<new_exec> to create processes, it should
 work though.
+=head1 USING AnyEvent::Fork IN SUBPROCESSES
+AnyEvent::Fork itself cannot generally be used in subprocesses. As long as
+only one process ever forks new processes, sharing the template processes
+is possible (you could use a pipe as a lock by writing a byte into it to
+unlock, and reading the byte to lock for example)
+To make concurrent calls possible after fork, you should get rid of the
+template and early fork processes. AnyEvent::Fork will create a new
+template process as needed.
+   undef $AnyEvent::Fork::EARLY;
+   undef $AnyEvent::Fork::TEMPLATE;
+It doesn't matter whether you get rid of them in the parent or child after
+a fork.
 =head1 SEE ALSO
 L<AnyEvent::Fork::Early>, to avoid executing a perl interpreter at all
 (part of this distribution).

Diff Legend

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

Comparing AnyEvent-Fork/Fork.pm (file contents): Revision 1.59 by root, Fri Aug 30 12:06:48 2013 UTC vs. Revision 1.63 by root, Wed Nov 26 13:36:18 2014 UTC

Diff Legend

Comparing AnyEvent-Fork/Fork.pm (file contents):
Revision 1.59 by root, Fri Aug 30 12:06:48 2013 UTC vs.
Revision 1.63 by root, Wed Nov 26 13:36:18 2014 UTC