The FS loader uses a vtable fs_library_vtable_t defined in fs-loader.h.
Some of the functions defined in the vtable have a common_pool
parameter:
/* The open_fs/create/open_fs_for_recovery/upgrade_fs functions are
serialized so that they may use the common_pool parameter to
allocate fs-global objects such as the bdb env cache. */
svn_error_t *(*create)(svn_fs_t *fs, const char *path, apr_pool_t *pool,
apr_pool_t *common_pool);
svn_error_t *(*open_fs)(svn_fs_t *fs, const char *path, apr_pool_t *pool,
apr_pool_t *common_pool);
In FSFS this common_pool gets passed to fs_serialized_init in fs.c where
it is used to setup setup mutexes:
status = apr_pool_userdata_get(&val, key, common_pool);
if (status)
return svn_error_wrap_apr(status, _("Can't fetch FSFS shared data"));
ffsd = val;
if (!ffsd)
{
ffsd = apr_pcalloc(common_pool, sizeof(*ffsd));
ffsd->common_pool = common_pool;
/* POSIX fcntl locks are per-process, so we need a mutex for
intra-process synchronization when grabbing the repository write
lock. */
SVN_ERR(svn_mutex__init(&ffsd->fs_write_lock,
SVN_FS_FS__USE_LOCK_MUTEX, common_pool));
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'm not sure how the absence of common_pool affects the BDB
implementations.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
