Thanks for the info. It all makes some sort of sense :) Jonathan Field
On Tue, 2 Dec 2003, Rafael Garcia-Suarez wrote: > Jonathan Field wrote: > > I was surprised that the "SCALAR(0x8ca70e4)" output was identical on > > subsequent requests to a child -- indicating to me that the ref (and what > > it was refering to) may have survived the request cycle? I guess would > > have expected a different ref, especially after running through the top > > part of the handler again, where it reinitializes them. I've included the > > code again below for convenience). > > To avoid allocating and reallocating lexical variables, perl > preallocates memory pads for them, in which they are stored. perl knows > how to allocate the pads and to which lexical scope to attach them via > the my() compile-time declaration. So, it's not surprising the address > of this value doesn't change between runs. > > > Also, the internal magic (switching from PV to PVMG) seems to survive the > > request cycle? Regardlesss of whether the $r->print() behavior is going > > to be changed, I was surprised that the regex from first request effected > > the behavior on the second request. > > Yes, this magic is used to attach matching positions to a string, or > something like that (can't remember precisely). Since the string > "hello\n" isn't destroyed between runs of the handler, magic stays > there. This is an unfortunate side-effect of pattern matching. Getting > rid of it would be a good thing, -- but would probably involve lots of > work on the scary regex engine. > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
