[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

FS vtable common_pool and pack_fs/recover

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 21 Aug 2012 18:00:23 +0100

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

  /* 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_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

Certified & Supported Apache Subversion Downloads:
Received on 2012-08-21 19:01:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.