From e8ec7aa8e38a93f5b034ac74cebce5de23710317 Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:45:08 -0500 Subject: upload http JIRA: BOTTLENECK-10 Change-Id: I7598427ff904df438ce77c2819ee48ac75ffa8da Signed-off-by: hongbotian --- .../httpd-2.0.64/srclib/apr/docs/pool-design.html | 100 +++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 rubbos/app/httpd-2.0.64/srclib/apr/docs/pool-design.html (limited to 'rubbos/app/httpd-2.0.64/srclib/apr/docs/pool-design.html') diff --git a/rubbos/app/httpd-2.0.64/srclib/apr/docs/pool-design.html b/rubbos/app/httpd-2.0.64/srclib/apr/docs/pool-design.html new file mode 100644 index 00000000..d862ff9c --- /dev/null +++ b/rubbos/app/httpd-2.0.64/srclib/apr/docs/pool-design.html @@ -0,0 +1,100 @@ + + + Using APR Pools + + +

+ Last modified at [$Date: 2004-11-24 23:02:04 +0000 (Wed, 24 Nov 2004) $] +

+ +

Using APR Pools

+ +

+ From Subversion, we + have learned a lot about how to use pools in a heavily + structured/object-based environment. + Apache httpd is a + completely different beast: "allocate a request pool. use + it. destroy it." +

+ +

+ In a complex app, that request-style of behavior is not + present. Luckily, the "proper" use of pools can be described in + just a few rules: +

+ +

+ Objects should not have their own pools. An object is + allocated into a pool defined by the constructor's caller. The + caller knows the lifetime of the object and + will manage it via the pool. Generally, this also means that + objects will not have a "close" or a "free" since those + operations will happen implicitly as part of the destruction + of the pool the objects live within. +
+
+ Functions should not create/destroy pools for their + operation; they should use a pool provided by the + caller. Again, the caller knows more about + how the function will be used, how often, how many times, + etc. Thus, it should be in charge of the function's memory + usage. +
+
+ As an example, the caller might know that the app will exit + upon the function's return. Thus, the function would be + creating extra work if it built and destroyed a + pool. Instead, it should use the passed-in pool, which the + caller is going to be tossing as part of app-exit anyways. +
+
+
+ Whenever an unbounded iteration occurs, a subpool should be + used. The general pattern is: +
+
+
```
+subpool = apr_create_subpool(pool);
+for (i = 0; i < n; ++i) {
+  apr_pool_clear(subpool);
+
+  do_operation(..., subpool);
+}
+apr_pool_destroy(subpool);
```
+
+
+ This pattern prevents the 'pool' from growing unbounded and + consuming all of memory. Note that it is slightly more + optimal to clear the pool on loop-entry. This pattern also + allows for a 'continue' to occur within the loop, + yet still ensure the pool will be cleared. +
+
+ Given all of the above, it is pretty well mandatory to pass a + pool to every function. Since objects are not + recording pools for themselves, and the caller is always + supposed to be managing memory, then each function needs a + pool, rather than relying on some hidden magic pool. In + limited cases, objects may record the pool used for their + construction so that they can construct sub-parts, but these + cases should be examined carefully. Internal pools can lead to + unbounded pool usage if the object is not careful. +

+ +

Greg Stein

+ + +Last modified: Wed Jun 25 14:50:19 PDT 2003 + + + -- cgit 1.2.3-korg