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). > 1 - I couldn't find the proceeding paper online, but this article seems to be > pretty close (same?) to the original paper: > http://www.perl.com/lpt/a/2002/05/07/optree.html > Highly recommended. > > p.s. and there is also the optimizer which we may find useful in our game: > http://archive.develooper.com/[EMAIL PROTECTED]/msg03732.html?x > > p.p.s.: google came up with the following interesting resources: > http://wiki.slowass.net/?PerlAssembly > http://www.faqs.org/docs/perl5int/compiler.html See also the perlcompile man page. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
