Rafael Garcia-Suarez wrote:
Stas Bekman wrote:

I'm not talking about mod_perl internals, just talking about amputating a chunk of the Optree from one interpreter and replanting it into another interpreter (not perl_cloned one).


You need to explain to me what those interpreters are. IIUC from your
remark below the first one is in the root httpd process to parse the
config file ; the other ones are in the child httpd processes to process
requests ? And you want to slim down the first one ? What are the CV
root and CV start of those interpreters ?

Why do you want to move CVs from the first one to the later ones ? Just
removing them from the first one is not enough ?

here is an idea of what we're talking about.


httpd.conf hits a <Perl> section, so mod_perl needs to launch the interpreter. the <Perl> section adds configuration directives httpd.conf and sets $Apache::Server::SaveConfig = 1, which means that the configuration is to be available via perl package variables at request time.

so, when this interpreter is cloned so a pool of them can service requests, that data needs to go with it . under the current situation, this all happens just fine, since clones carry with them copies of everything (or so I read :)

however, because the interpreter was started when <Perl> was parsed, any modules that are use()d after the interpreter gets started (via startup.pl, PerlModule, or whatever) are _also_ added to the interpreter and copied. this is bad for a few reasons, namely that request-time processing may not need the packages (if they were used only for config parsing), and that the interpreter cloning required when the request pool is expanded takes an extremely long time.

so, what would be ideal is to clone a _different_ interpreter than the one that parsed <Perl>, thus giving us the ability to clone an interpreter with no loaded modules at all. this would greatly reduce the time it takes to clone interpreters for the request pool, thus increasing request-time performance.

the problem with this, though, is that we don't really want a clean interpreter, we want an _almost_ clean one - one with only the data we know is important (like the globals set within the <Perl> section). so, if we could copy the relevant data from the first interpreter and insert it into the one we're about to clone for the request, we'd have the best situation possible - minimal data in the parent interpreter.

or something like that :)

--Geoff


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to