perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Fri, 02 Jul 2004 17:28:19 GMT
Stas Bekman <> 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.


[...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:
For additional commands, e-mail:

View raw message