apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Changing the order of cleanup for some core objects
Date Wed, 23 Jul 2008 08:30:47 GMT
On Wed, 2008-07-23 at 10:07 +0200, Mladen Turk wrote:

> That's my point.
> The API is very unclear in that case and you *must* follow
> certain rules.

Well, you definitely must follow certain (head scratching :-) rules
right now as well.

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

> Also additional pool is always created for each resource which
> might not be what user needs


> (not to mention the API change
> in that case, since original says that constructor is provided
> with the pool used for apr_reslist).

Also agreed.

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"


View raw message