Re: Changing the order of cleanup for some core objects

[Mladen Turk]

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)