On 09.01.2011 21:09, Blair Zajac wrote:
> Wanted to confirm a reading of fs_serialized_init() in
> libsvn_fs_fs/fs.c in a persistent, multithreaded server.
>
> It appears that if fs_serialized_init() is called at the same time by
> two or more threads, then you would have a race on
> apr_pool_userdata_get() and apr_pool_userdata_set().
>
> It looks like a good fix for this would be to have svn_fs_initialize()
> call down into the fs implementation library to set this up? Would
> that be a good solution to this? It would need to call into all fs
> implementation libraries though, loading a .so that may never be used.
That is indeed one way to fix this problem. The trouble with the 1.0
API, on all levels, is that it does not require the user to call an
initialization function in a single-threaded context. This leads to all
sorts of hacks to work around a missing requirement that can't be
imposed retroactively without changing the major version.
I guess it should be enough if we could guarantee: a) that we initialize
the implementation DSO as soon as it's loaded (but have to somehow
serialize the loading), and never, ever unload a DSO (but then have to
make sure that some random pool cleanup won't unload it for us). IIRC
we've tried both.
-- Brane
Received on 2011-01-10 03:57:53 CET