Stas Bekman wrote:
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).
Fudging with the optree is probably not the way to go. I think that what you want, if I understand correctly, is moving stashes into new interpreters. CVs live in stashes and maintain a pointer to the optree that implements them. And the bulks of ops are in subroutines.
Moving CVs won't be straightforward, though, because you need to watch out for closures (CvOUTSIDE).
Yup, that was the (theorethical) idea. I'm not sure how practical it is.
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?
__________________________________________________________________ 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]
