On 19.04.2014 17:12, Ivan Zhakov wrote:
> On 19 April 2014 16:44, <stefan2_at_apache.org> wrote:
>> Author: stefan2
>> Date: Sat Apr 19 12:44:07 2014
>> New Revision: 1588651
>>
>> URL: http://svn.apache.org/r1588651
>> Log:
>> Reduce the size of an FSFS instance by using temporary pools
>> for temp. data during fs_open().
>>
>> * subversion/libsvn_fs_fs/fs_fs.h
>> (svn_fs_fs__initialize_caches): Document that the POOL shall be
>> used for temporaries only.
>>
>> * subversion/libsvn_fs_fs/caching.c
>> (svn_fs_fs__initialize_caches): Fix the only place where we used
>> POOL instead of FS->POOL for
>> something with svn_fs_t lifetime.
>>
>> * subversion/libsvn_fs_fs/fs.c
>> (fs_serialized_init): Document POOL usage that we will now rely on.
>> (fs_open): Use a SUBPOOL for anything temporary during FS init.
>>
> Just creating subpool for temporary allocation violates pool design
> imho. Proper fix would be add scratch pool parameter to
> svn_fs_open()/svn_fs_create().
Doesn't "violate" it, as such ... there's a balance to be maintained
here. Adding a scratch-pool parameter means revising the API and
propagating the revision up the call chain to all the places where a
meaningful scratch pool is already available. Sure it's better to do do
that in the long run; but does the change warrant the related code churn
now? Consider that there's a vtable involved here, too.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-04-19 17:26:00 CEST