apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Changing the order of cleanup for some core objects
Date Wed, 23 Jul 2008 09:23:49 GMT
Bojan Smojver wrote:
> 
>> Again you cannot call pool_create in constructor
>> and then pool_destroy in destructor without segfaulting, and
>> that bring us to the original problem.
> 
> If you create a sub-pool in your constructor (or during resource use),
> you do not need to destroy it in the destructor, because when the pool
> specific to the resource is destroyed (and it always is), it will go
> away automatically. If you destroy any sub-pools during the course of
> the resource use, that's safe too. So, it less to worry about, really.
> 
> This can all be properly documented, of course.
>

Well but what if I need that pool in destructor?
It'll be long gone before destructor is called.

> 
> Maybe we can have a new API for reslists (call it
> apr_reslist_create_ex()) where we have an argument to specify if we want
> that per-resource pool, pre_cleanups or not. Then people get the
> behaviour they want:
> 
> 1. Default: today's broken reslist, as per 1.3.x
> 2. Don't create per-resource pool: rely on pre_cleanups
> 3. Create per-resource pool: rely on the "design pattern"
> 

IMHO reslist should do what is says:
For each resource there is constructor/destructor and it's
the API user responsibility to cleanup any resources in
destructor that have been allocated in the constructor.
... very nice, simple and clean thought.


Regards
-- 
^(TM)

Mime
View raw message