Tom Schindl wrote:
> Does this really make sense? You are printing the pointer of the pointer
> to the apache request object.
You're right, I've should have printed $r, which yields:
Apache2::RequestRec=SCALAR(0x9d44644) [first n times]
Apache2::RequestRec=SCALAR(0x9d7e0a4)
(n begin the number of apache children)
Am I correct in assuming that the Apache2::RequestRec object is now sitting
in 0x9d44644 or is that just the mem address of the scalar, which changes,
but is still pointing to the same RequestRec.
Anyway, In both cases, my question still remains, howcome the handler stays
the same for all children once, and then changes to another memory
location? ie: I'm using Template::Magic, and if I do something like:
our $t = new Template::Magic(...);
handler () {
my $r = shift;
my %hash = ( x => 1 );
$r->print($t->nprint(... lookup => [\%hash] ...));
return OK;
}
I get an output with an Array and Hash reference in it (don't know why, but
if I use $r->print(Dumper($t->nprint(...))) I can see it's the %hash of
template associated variables). And this behaves quite the same way as I
described earlier, it seems like the Array and Hash are relocated (?) every
n-th hit.
The reason I started investigating this, is because Template::Magic uses a
cache, and I assumed this behaviour would not allow caching more then n
times, since the object is re-new()ed. (I was wrong though, $t stays the
same all the time until server restart, but it got me wondering why the
handler does sometimes seem to relocate)
ps: I've been tinkering way too much, and could be overseeing the simplest
things (like \$r in my previous message).
> Moreover as far as I know perl reuses space allocated space (hence it's
> not freed) that's why you should not use fileuploads with mod_perl.
I see, so it might not be such a good idea to use Cache::Cache or does
it's purge method really deallocate the memory?
> Tom
--
kind regards,
Tim
