perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Fri, 02 Jul 2004 17:49:27 GMT
Joe Schaefer wrote:

>>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;
>   }

Right, nice! May be you want to document why you did so, so others can grok 
your code too. Doug wrote lots of really tricky code and hardly left any 
comments, leaving us wondering about what certain chunks of code do, leading 
to a lot of wasted time.

> 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).

I'm not sure what's more effective:
- attaching magic (no extra code required to cleanup)
- incrementing the pool obj refcount on entry and provide DESTROY to decrement 
it (though one needs to stash that obj somewhere)
- tag the pool (as APR::Pool does internally)

Thought don't forget that this is all complicated by the ability of Apache to 
destroy the pool, w/o notifying the object. Though APR::Pool should take care 
of handling that.

I don't think I'm going to even start with that now, unless someone beats me 
to it, I'm back to work on finishing the API. As this issue doesn't affect the 
API it can wait.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message