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