This may be old news to some, but I wrote an article about this about two months ago on Perlmonks: Things you need to know before programming Perl ithreads.
http://www.perlmonks.org/index.pl?node_id=288022
Yup, you kindly pointed me to it when you wrote it. It's a very good article.
I hadn't seen it yet - thanks for pointing it out.
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...
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
