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.
Received on 2011-05-26 00:52:14 CEST