IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 +
Hi Richard,
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of
code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at
Hello,
I have been working with this exact subject for the past couple weeks and
becnhmarking lots of results. Although I dont have the results here to
show, we have decided to use PVM (
http://www.epm.ornl.gov/pvm/pvm_home.html ) to spawn subprocces on other
machines and also on the same
On Wed, Oct 04, 2000 at 02:42:50PM -0700, David E. Wheeler wrote:
Yeah, I was thinking something along these lines. Don't know if I need
something as complex as IPC. I was thinking of perhaps a second Apache
server set up just to handle long-term processing. Then the first server
could
I'm working with the Swish search engine (www.apache.org and the guide use
it).
Until this month, SWISH could only be called via a fork/exec. Now there's
an early C library for swish that I've built into a perl module for use
with mod_perl.
Yea! No forking!
I decided to do some quick
On Thu, 5 Oct 2000, Sean D. Cook wrote:
On Wed, Oct 04, 2000 at 02:42:50PM -0700, David E. Wheeler wrote:
Yeah, I was thinking something along these lines. Don't know if I need
something as complex as IPC. I was thinking of perhaps a second Apache
server set up just to handle
-Original Message-
From: David E. Wheeler [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 04, 2000 3:44 PM
To: [EMAIL PROTECTED]
Subject: Forking in mod_perl?
Hi All,
Quick question - can I fork off a process in mod_perl? I've
got a piece
of code that needs to do a
Hi David,
Check out the guide at
http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subprocess
The Eagle book also covers the C API subprocess details on page 622-631.
Let us know if the guide is unclear to you, so we can improve it.
Ed
"David E. Wheeler" wrote:
Hi All,
I was just going to post that url to the guide also... But another option
I've come up with not listed in the guide is to use the *nix "at" command.
If I need to run some processor intensive application that doesn't need
apache_anything, I'll do a system call to "at" to schedule it to run
ed phillips wrote:
Hi David,
Check out the guide at
http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subprocess
The Eagle book also covers the C API subprocess details on page 622-631.
Let us know if the guide is unclear to you, so we can improve it.
Yeah, it's
I hope it is clear that you don't want fork the whole server!
Mod_cgi goes to great pains to effectively fork a subprocess, and
was the major impetus I believe for the development of
the C subprocess API. It (the source code for
mod_cgi) is a great place to learn some of the
subtleties as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 4 Oct 2000, ed phillips wrote:
Now you are faced with a trade off. Is it more expensive to
detach a subprocess, or use the child cleanup phase to do
some extra processing? I'd have to know more specifics to answer
that with any modicum
ed phillips wrote:
I hope it is clear that you don't want fork the whole server!
Mod_cgi goes to great pains to effectively fork a subprocess, and
was the major impetus I believe for the development of
the C subprocess API. It (the source code for
mod_cgi) is a great place to learn some
Billy Donahue wrote:
Now you are faced with a trade off. Is it more expensive to
detach a subprocess, or use the child cleanup phase to do
some extra processing? I'd have to know more specifics to answer
that with any modicum of confidence.
He might try a daemon coprocesses using
On Wed, Oct 04, 2000 at 02:42:50PM -0700, David E. Wheeler wrote:
Yeah, I was thinking something along these lines. Don't know if I need
something as complex as IPC. I was thinking of perhaps a second Apache
server set up just to handle long-term processing. Then the first server
could send a
I use a database table for the queue. No file locking issues, atomic
transactions, you can sort and order the jobs, etc . . . you can wrap the
entire "queue" library in a module. Plus, the background script that
processes the queue can easily run with higher permissions, and you don't
have to
David E. Wheeler writes:
Using the cleanup phase, as Geoffey Young suggests, might be a bit
nicer, but I'll have to look into how much time my processing will
likely take, hogging up an apache fork while it finishes.
I've wondered about this as well. I really like the cleanup handler,
17 matches
Mail list logo
