[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Using APR pools "better"

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 26 Sep 2018 15:20:01 +0000

Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400:
> At ApacheCon's welcoming event last night, Greg, Sander and I were
> chatting and Greg reminded us that the Subversion project "learned a lot
> about using APR pools" and it seems to me that a lot of that knowledge
> is likely missing in httpd-land. I also know that some of that has been
> backported back to APR itself, but I am wondering (as I am wont to do),
> if we couldn't do a better job here. I am sure that there are things in
> svn that could be easily and readily folded back into APR w/o breaking
> anything.
> I know that some of that influenced Greg's PoCore work, but it would be
> really cool if someone in Subversion could maybe point out some of those
> improvements and "lessons learned" so that both APR and httpd could
> benefit.

For starters, here's what we've already written down:


I would especially point out the result_pool/scratch_pool distinction:
each function gets *two* pools, one in which to allocate the return
value, and one whose lifetime is defined as "the pool may be deleted at
any time after the function returns".

For example, when one calls a function declared as:
    apr_status_t find_foo(foo_t *outparam, ..., apr_pool_t *result_pool, apr_pool_t *scratch_pool)
then on return *outparam will be allocated in result_pool, and
apr_pool_clear(scratch_pool) may be called as soon as find_foo()
returned. Thus, scratch_pool is passed into the result_pool formal
parameter of functions find_foo() calls, is the pool iterpools are created
as subpools of, etc. .

I'm sure Greg is subscribed to at least one of these lists and will add anything I forgot :)

Received on 2018-09-26 17:20:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.