On Wed, Sep 26, 2018 at 04:15:19PM -0500, Greg Stein wrote: > iterpool, scratch_pool, and result_pool are the KEY three concepts that we > learned while working on Subversion.
Here's a recent example of where and why we added an iterpool (which should have been added when this loop was written in the first place): Log message: http://svn.apache.org/viewvc?view=revision&revision=1841725 Diff: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/conflict-callbacks.c?r1=1841725&r2=1841724&pathrev=1841725 There is a key difference between Subversion and HTTP which affects pool lifetime concerns: SVN (on the client side) is a blocking application, while HTTPD is event-driven. Pools in HTTPD are often bound to the lifetime of a HTTP request (event) which means they are short-lived by design. Global data stored in pools is of a relatively fixed size. Whereas Subversion's client library is often used in a long-running process context (such the Windows Explorer in case of TortoiseSVN). The svn command line client alternates between blocking for user input and calling into the client library. The client library will return results to these API users and it has no idea about the lifetimes its callers require. Which is why letting the caller manage pool lifetime is a natural thing to do for this application. If you are going to write some general pool usage recommendations for APR I suppose such docs should mention how the various pool usage models relate to the software architectures they were invented for.
