apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r942897 - in /httpd/httpd/trunk: CHANGES server/mpm/prefork/prefork.c
Date Fri, 21 May 2010 17:50:30 GMT
On Wed, May 19, 2010 at 5:26 PM, Joe Orton <jorton@redhat.com> wrote:
> On Wed, May 12, 2010 at 03:30:29PM -0400, Jeff Trawick wrote:
>> The multiple-calls-to-pool_clear solution is definitely safer.
>
> OK, so now I reviewed that too ;) The only difference between:
>
>   apr_pool_clear(ptrans);
>   apr_pool_destroy(pchild);
>
> and simply:
>
>   apr_pool_destroy(pchild);
>
> (given that ptrans is a child of ptrans and _destroy runs cleanups in
> child pools)
>
> is that it hides problems in cleanup ordering/pool nesting.

hmmm, definitely a negative characteristic...  too bad it is
(apparently) rolled up in the following issue

> I think PR 43857 is about the reslist cleanup issue in APR-util, r677505
> and all that.  Not sure what the status of that is.

main, initial discussion ends here:
http://marc.info/?l=apr-dev&m=121728874016894&w=3

meanwhile, unreleased apr trunk and unreleased apr-util 1.4.x have

APU_DECLARE(void) apr_reslist_cleanup_order_set(apr_reslist_t *rl,
                                                apr_uint32_t mode)
{
    apr_pool_cleanup_kill(rl->pool, rl, reslist_cleanup);
    if (mode == APR_RESLIST_CLEANUP_FIRST)
        apr_pool_pre_cleanup_register(rl->pool, rl, reslist_cleanup);
    else
        apr_pool_cleanup_register(rl->pool, rl, reslist_cleanup,
                                  apr_pool_cleanup_null);
}

and apr_memcache uses that

discussion of backporting seems to have stopped at this point:
http://marc.info/?l=apr-dev&m=121661852120171&w=3

Mime
View raw message