Daniel Shahaf <d...@daniel.shahaf.name> writes: > Philip Martin wrote on Tue, Aug 21, 2012 at 18:00:23 +0100: >> Functions like fs_library_vtable_t.pack_fs and >> fs_library_vtable_t.recover that don't take the common_pool parameter >> pass the pool parameter to fs_serialized_init. I think that means these >> functions should only be used from a single threaded process. >> >> Is that correct? If so we should document it or change the functions to >> handle the common_pool. >> > > I think the correct fix is to propagate common_pool to have fs_pack() > and pass it as to the appropriate parameter of fs_serialized_init().
Yes, I think that would be correct. It's probably possible to backport to 1.7 since these functions are all private. >> I'm not sure how the absence of common_pool affects the BDB >> implementations. > > Is it even used? A quick grep in libsvn_fs_base suggests that only fs.c > has variables by that name; therein, only svn_fs_base__init() uses them; > and that function seems to have no callers(!?). It's called by the FS dynamic loader via a function pointer when get_library_vtable_direct calls initfunc. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
