Author: stas
Date: Fri Feb 18 18:11:41 2005
New Revision: 154383
URL: http://svn.apache.org/viewcvs?view=rev&rev=154383
Log:
some discussing of whether spawn_proc_prog is any good for doing parallel
processing
Modified:
perl/modperl/docs/trunk/src/docs/2.0/api/Apache/SubProcess.pod
Modified: perl/modperl/docs/trunk/src/docs/2.0/api/Apache/SubProcess.pod
URL:
http://svn.apache.org/viewcvs/perl/modperl/docs/trunk/src/docs/2.0/api/Apache/SubProcess.pod?view=diff&r1=154382&r2=154383
==============================================================================
--- perl/modperl/docs/trunk/src/docs/2.0/api/Apache/SubProcess.pod (original)
+++ perl/modperl/docs/trunk/src/docs/2.0/api/Apache/SubProcess.pod Fri Feb 18
18:11:41 2005
@@ -57,6 +57,8 @@
threads, e.g. that's how it's running mod_cgi on win32).
+
+
=head1 API
@@ -120,6 +122,21 @@
L<Synopsis|/Synopsis> section.
Several examples appear in the L<Synopsis|/Synopsis> section.
+
+C<spawn_proc_prog()> is similar to C<fork()>, but provides you a
+better framework to communicate with that process and handles the
+cleanups for you. But that means that just like C<fork()> it gives you
+a different process, so you don't use the current Perl interpreter in
+that new process. If you try to use that method or fork to run a
+high-performance parallel processing you should look elsewhere. You
+could try Perl threads, but they are B<very> expensive to start if you
+have a lot of things loaded into memory (since C<perl_clone()> dups
+almost everything in the perl land, but the opcode tree). In the
+mod_perl "paradigm" this is much more expensive than fork, since
+normally most of the time we have lots of perl things loaded into
+memory. Most likely the best solution here is to offload the job to
+PPerl or some other daemon, with the only added complexity of
+communication.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
