Geoffrey Young wrote: [...]
So, in the worker mpm, you need to load as little as possible before cloning, and only load modules when they are really needed inside the thread. This is perpendicular to prefork mpm, where you want to load as much as possible beforehand.
The problem is with 3rd party modules, which may load things they may never use, by calling 'use module' on the top, instead of calling 'require module' where it's really needed. So you end up with dozens of modules loaded that you don't really use. Too bad we can't unload modules.
it seems to me it doesn't need to be this way.
I haven't looked at the interpreter pool code (and probably wouldn't get it anyway) but I'm wondering if we can't improve things on our side a bit just by juggling things around some. so, if you can follow my stream of consciousness for a moment... :)
the first thing that jumps to mind is that PerlModule inclusion is already delayed. so, theoretically, we could delay that inclusion until after the interpreter is cloned, right? that's essentially what Liz says is the best solution in her article. have the inclusion be the first thing an interpreter does when it's added to the pool, before it's available for use?
in practice, where this might be a problem is that the interpreter can be started early due to <Perl> sections, etc. I've been wondering for a while now if it's required that we clone _this_ interpreter. that is, why can't we have PerlSwitches -T work even if <Perl> starts _an_ interpreter - why not fork (or something) off a separate perl process for httpd.conf-related things then clone the (prisine, lightweight) interpreter after parsing? or something like that :)
what I'm getting at (without a full understanding of the issues involved) is that we probably can be a bit smarter about this if we redesign things a bit, knowing now what the issues are. and it seems like we're already part of the way there with the way PerlModule already behaves.
just some random thoughts...
I've suggested that long time ago and we have discussed the idea here. It can't work the way you (and I) suggested. Since PerlLoadModule loads things into *the* interpreter that you will need to access later during the request time. Same goes for <Perl>. What you really need is to be able to rip off those wanted at run-time chunks of the OpCode tree and re-plant them into the new interepreters. It's quite possible that we could do that but I don't think we have the easy way to do it now. We can certainly manipulate the tree with B::Generate (see Simon Cozen's paper in TPC proceedings 2001 [1], which was about manipulating the OpCode tree) and do selective copying (transplanting).
1 - I couldn't find the proceeding paper online, but this article seems to be pretty close (same?) to the original paper: http://www.perl.com/lpt/a/2002/05/07/optree.html
Highly recommended.
p.s. and there is also the optimizer which we may find useful in our game: http://archive.develooper.com/[EMAIL PROTECTED]/msg03732.html?x
p.p.s.: google came up with the following interesting resources: http://wiki.slowass.net/?PerlAssembly http://www.faqs.org/docs/perl5int/compiler.html
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
