Rafael Garcia-Suarez wrote:
Stas Bekman wrote:

How about this (yet another) idea. Snapshot the OpCode tree before and after running the <Perl> sections (or PerlLoadModule). Then traverse both OpCode trees and somehow rip off the differences and transplant them into the newly perl_clone()'d interpreters. We prefer to sustain a delay at the startup, versus run-time. Any surgeons out there?


I'm not sure what you mean there (lack of knowledge of mod_perl internals),
but the optrees aren't cloned, be it the main optree or the CV optrees.

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). I'm not sure whether this is possible at all. I really want some sort of Storable::freeze, so I can save a CV and all the related SVs and then resurrect them with ::thaw in another interpreter.


To repeat, the problem we have is that we start perl early to do config parsing (.e.g code run in <Perl> sections) and we really want to kill that perl when it finished dealing with config, but we need the perl data it generated to be resurrected in the perl that will process the requests.

__________________________________________________________________
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]



Reply via email to