On 27.01.2015 13:38, Philip Martin wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
>> Where should we introduce dual pools?
> Every function that returns a result allocated in a pool is a candidate.
> I think it requires more justification for such a function to be single
> pool.
>
>> The callstack is single-pool all
>> the way to the public entry point svn_version_extended().
> Maybe svn_version_extended() should have been dual pool from the start.
Maybe it should have been. My thinking at the time was that this
function is only called from 'svn --version --verbose' so the fact that
it uses a single pool doesn't really affect memory footprint. An API
user may have to copy the important info out of the pool passed to this
function; I suggest the best thing to do is to add a warning to the
docstring of that function.
Alternatively, svn_version_extended itself can create a scratch pool and
propagate it down the stack. That's better than revising the function
itself; in this case, none of the performance- or memory
footprint-related arguments apply.
-- Brane
Received on 2015-01-27 14:08:46 CET