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.
Received on 2018-09-27 09:30:32 CEST