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
> 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
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()
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. .
This is a bit unclear, so skip this and go read the page :-)
I'm sure Greg is subscribed to at least one of these lists and will add anything I forgot :)
All three, actually :-) ... and the pointer to the coding convention page is exactly what I wanted to point the other groups at.
iterpool, scratch_pool, and result_pool are the KEY three concepts that we learned while working on Subversion. Also relying on your *caller* to know more about memory management / lifetimes. The conventions page does a really great job of describing what we learned, and we're here to expand/answer where it isn't (and #fixthedoc :-P ), and/or provide further examples to clarify.