On 27.01.2015 13:38, Philip Martin wrote: > Daniel Shahaf <d...@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
