Sander Striker
Wed, 23 Jul 2008 07:30:22 -0700
On Wed, Jul 23, 2008 at 4:22 PM, Mladen Turk <[EMAIL PROTECTED]> 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) >