On 18.05.2011 12:13, Daniel Shahaf wrote:
I found the docstring of the deserializer function types unclear as to the use of @a POOL...So, the following patch attempts to clarify the role of pools in that interface: [[[ Index: subversion/include/private/svn_cache.h =================================================================== --- subversion/include/private/svn_cache.h (revision 1124156) +++ subversion/include/private/svn_cache.h (working copy) @@ -50,16 +50,16 @@ extern "C" { /** * A function type for deserializing an object @a *out from the string - * @a data of length @a data_len in the pool @a pool. + * @a data of length @a data_len into @a result_pool. */ typedef svn_error_t *(*svn_cache__deserialize_func_t)(void **out, const char *data, apr_size_t data_len, - apr_pool_t *pool); + apr_pool_t *result_pool);
<snip>
]]]
Committed as r1127705.
Also, should (some of) these functions convert to the dual-pool paradigm?
The only place where that would be somewhat useful are the "partial" getters and setters. However, even those functions will be called in tight loops, i.e. the pools have already very short lifetimes and allocating a few more temporary bytes in the target pool won't do harm. Having additional pools may even increase memory consumption (slightly) due to internal allocation granularity. -- Stefan^2.
