Re: [Fwd: Re: How to reload PERL module in all Apache children]
if you use Apache::Reload with a threaded MPM and multiple interpreters, the modules will be reloaded by each interpreter as they are used, not every interpreter all at once. similar to 1.x where each child has its own interpreter, the modules are reloaded as each kid is hit with a request. note that if a module is loaded at startup, the syntax tree of each subroutine is shared between interpreters (big win), but each subroutine has its own padlist (where lexical my variables are stored). once Apache::Reload reloads a module, this sharing goes away and each interpreter will have its own copy of the syntax tree for the given subroutines.
Re: [Fwd: Re: How to reload PERL module in all Apache children]
[EMAIL PROTECTED] wrote: if you use Apache::Reload with a threaded MPM and multiple interpreters, the modules will be reloaded by each interpreter as they are used, not every interpreter all at once. similar to 1.x where each child has its own interpreter, the modules are reloaded as each kid is hit with a request. thanks for correcting me. It's all about interpreters and not threads, so it's the same for the code with forked and threaded httpds. But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? Also if we put the sharing aside for a moment and assuming that we have a pool of interpreters with idle interpreters in it, there can be a thread that monitors changed modules and update the idle interpreters by making them reload the code and put them in the head of the list. This should save the overhead of reloading during a request. Does this make sense? __ Stas BekmanJAm_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
Re: [Fwd: Re: How to reload PERL module in all Apache children]
On Fri, 12 Apr 2002, Stas Bekman wrote: But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? even if that would work, it would kill performance due to required mutex locking. and that locking would need to happen in the perl core, unlike simple scalars, arrays and hashes. Also if we put the sharing aside for a moment and assuming that we have a pool of interpreters with idle interpreters in it, there can be a thread that monitors changed modules and update the idle interpreters by making them reload the code and put them in the head of the list. This should save the overhead of reloading during a request. Does this make sense? there already is a plan to have a low-priority thread that monitors idle interpreters. this would be a pluggable interface, so you can do whatever you want with the interpreter via callback hooks. but that'll all wait until well after everything else is solid with ithreads, including and most important: perl 5.8.x
Re: [Fwd: Re: How to reload PERL module in all Apache children]
[EMAIL PROTECTED] wrote: On Fri, 12 Apr 2002, Stas Bekman wrote: But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? even if that would work, it would kill performance due to required mutex locking. and that locking would need to happen in the perl core, unlike simple scalars, arrays and hashes. Does it look you'll be able to get the solar variables idea to work for those data types? - Perrin
Re: [Fwd: Re: How to reload PERL module in all Apache children]
On Thu, 11 Apr 2002, Perrin Harkins wrote: Does it look you'll be able to get the solar variables idea to work for those data types? i had a simple prototype way back that sorta worked for simple scalars, probably won't take it any further now that there is threads::shared in 5.7.x. haven't tried it but i believe the concept is the same.
