perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: [mp2] perl_clone takes 5 and more seconds to complete
Date Mon, 10 Nov 2003 14:27:09 GMT

>> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message