Greg Hudson <ghudson_at_MIT.EDU> writes:
> Are there any practical problems which are solved by a scratch pool and
> a result pool?
>
> Our old discipline was:
>
> * Pass a pool which is used for scratch and results.
> * If you're going to loop, use a subpool.
> * Be streamy (don't read whole files into memory).
>
> So every scratch allocation should be constant. The memory usage from
> this discipline is O(stack size), which is generally not all that large.
This implies that if a caller wants to keep a result longer than the
loop_pool allows, it needs to copy that result into a different pool
(one that was not passed to the callee). That works until the result is
some opaque object for which there is no dup() function.
You may have been asking for concrete examples, and I don't have any of
those. I'll try to keep an eye out as I'm coding, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-07 23:21:00 CEST