apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <s.stri...@striker.nl>
Subject Re: Changing the order of cleanup for some core objects
Date Wed, 23 Jul 2008 14:29:35 GMT
On Wed, Jul 23, 2008 at 4:22 PM, Mladen Turk <mturk@apache.org> wrote:
> Joe Orton wrote:
>>
>> To be clear, I am not trying to argue that this problem can be easily
>> fixed given the constraints of the current reslist API.  But the APR pools
>> design has lasted essentially intact for over 10 years; I will continue to
>> be concerned about any line of argument which goes:
>>
>> 1. we designed this API, shipped it, woo
>> 2. oh dear, seems the API doesn't really work well with APR pools
>> 3. hmmm, but we can't change the API now since it's shipped
>> 4. so we need to change APR pools!
>>
>> Obviously, however much you change APR pools, people will still be able to
>> follow this line of argument.  So we need to differentiate between merely
>> being at step (2) of that road to nowhere and finding a case for a generally
>> useful enhancement to the pools API.
>>
>
> That would be mine concern as well if pool API was changed.
> It wasn't changed a bit except adding the possibility to have
> pre_cleanup that behaves like:

Addition is a change.  A notable one, as you're stuck with it for the
lifetime of a major release.  As you've noticed with
apr_pool_core_create_ex, it's not to be taken too lightly.  This
thread is partly about whether the addition is really warranted, or
whether there are existing ways of accomplishing the same.

I think in this thread some important details around pools have come
up that have caused additional thought, the primary one being the
intentional non-thread safety of pools.

Cheers,

Sander

> apr_pool_create(&s, pool)
> apr_pool_cleanup_register(s, foo, cleanup)
> ...
> apr_pool_create(&bar, pool)
> /* Always make sure it's executed first */
> apr_pool_cleanup_kill(s, foo, cleanup)
> apr_pool_cleanup_register(s, foo, cleanup)
> ...
>
> is actually the:
> apr_pool_pre_cleanup_register(pool, foo, cleanup)
>
> Without a need to create an extra pool and making sure
> it's a last one. Nothing more.
>
> Regards
> --
> ^(TM)
>

Mime
View raw message