Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> Scope of pools is a tricky thing. So all the APIs relying on a user
> providing the pool explicitly are potentially problematic at the moment.
+1.
[...more late night gibberish from me...]
> > Here somebody would need to call APR::Pool->DESTROY
> > to actually relinquish the last pool.
>
> Only the last one? I'm not quite sure how are you going to clean up
> the pool of pools. How do you know that you pop the right pool?
Sorry, please forget it- my "flyweight" suggestion makes no
sense whatsoever for this problem.
> What really needs to happen is to make the $pool object (or the temp)
> be tied to the object it belongs to ($apreq, $r, etc) and
> automatically get its refcount to 0 when the corresponding parent
> object goes out of scope. Which I suppose can be done with a simple
> DESTROY method. So when we accept the pool object we bump up its ref
> count and when DESTROY is called it'll decrement this count (this is
> because there could be more than one object using the same pool).
>
> I saw your commit -- if I understand it correctly, you try to make it
> dependent on the parent, so it won't get its refcount to 0 before the
> parent go away, right?
Correct. It's exactly like doing this:
package Mine;
sub new {
my ($class, $parent) = @_;
bless { my_stuff=> "blah", my_parent => $parent}, $class;
}
except that in apreq2 I stuffed the parent into a previously unused
SvMAGIC slot. I think the same plan will work for APR:: objects that need
a pool for their construction (in fact I'm wondering if all the WrapXS
machinery can't be put to use for this).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
