On Sat 17 May 2008, kropotkin wrote:
> say a request is made which via a Location directive and
> PerlResponseHandler directive is handled by my Perl module say Handler1.pm
> , ok a child process is spawned with mod_perl embedded which also loads and
> compiles Handler1.pm. Ok. If another request is made to Handler1.pm subject
> to the child process not having been killed by the parent I understand that
> this same child process will handle this new request. But if a request is
> made to
> Handler2.pm would this always result in a new child process or could the
> first process handle this request as well - just adding the code for
> Handler2.pm to its process space?
I assume you are using the prefork MPM.
At first try to figure out what the "pre" in prefork-MPM means. Apache does
not create its worker processes at request time but always has a few idle
processes hanging around waiting for requests. So at request time no process
has to be forked off.
Now you have configured your request to be handled by mod_perl. In this case a
perl interpreter resides inside the apache processes. It works similar to the
following code snippet:
$|=1;
$/="\n\n";
print "enter a code block> ";
while(<>) {
print eval $_;
warn "$@" if($@);
print "enter a code block> ";
}
This piece of code prints a prompt and waits for you to enter a code chunk. An
empty input line finalizes the code chunk. Then the perl interpreter
evaluates the chunk and prints the result. If there was an error a warning
message is printed. Then comes the next prompt.
So what happens if you enter a chunk like:
use Data::Dumper;
Dumper({a=>1, b=>[qw!a b c!]});
The Perl interpreter loads the Data::Dumper module and calls a function from
it.
Next time you enter the same chunk the perl interpreter will notice that the
Data::Dumper module is already loaded and only call the function.
Next time you may enter this piece:
use LWP::UserAgent;
LWP::UserAgent->new->get("http://foertsch.name/";)->content;
Now the perl interpreter loads the LWP::UserAgent module but the Data::Dumper
module still remains in core because the perl interpreter is the same.
This example shows a few points:
1) no extra process is forked for each request. This is the main advantage of
mod_perl over CGI where each request is processed by a separate process.
2) Once a module is loaded it remains in memory no matter whether it is used
again. So, if the current request doesn't need a module that modules memory
is wasted.
3) Modules may interact with one another. This may be wanted or not. But
modules must be aware that they are not alone.
4) you have a long running perl interpreter. That means opened files that are
forgotten by a piece of code remain open. The same is true for other things
concerning the process as a whole like chdir, signal handlers/masks etc.
Now mod_perl works similar to this little example. When a request enters an
apache worker and it decides to hand it over to mod_perl then perl
interpreter just executes a piece of code. Each request that hits that worker
process uses the same perl interpreter.
With the worker MPM the situation is a bit more complex but the idea of the
argument remains valid. One perl interpreter handles many requests.
Torsten
--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]
