On Sun, 2004-08-15 at 10:29, Peter N. Lundblad wrote:
> But apr_pool_userdata_{get,set} aren't thread-safe, so you can't use them
> on the same pool in different threads simultanously.
Yeah, I think this is the lynchpin of the problem.
> Oh, had we only had init routines that were required to be called
> by the user!
What would we do with them? We could add one, and just say that xlate
handle caching isn't very good unless you call it. But adding an
initializer before 1.1 frightens me, since we wouldn't really have a lot
of time to consider the API design.
(Also, if you're going to use the init routine to initialize a global
lock, I think that would hurt the MP performance of apps which use svn.
Right now, if you have N threads performing svn operations, each with a
totally independent pool, they won't lock against each other. But if
you add a global lock in a frequently-used low-level routine, that
changes.)
I think I've identified an alternative. The APR pool code locks pools
(or rather, locks the allocator which I believe is shared between all
pools in a tree of pools) like this:
#if APR_HAS_THREADS
apr_thread_mutex_t *mutex;
mutex = apr_allocator_mutex_get(allocator);
if (mutex != NULL)
apr_thread_mutex_lock(mutex);
#endif /* APR_HAS_THREADS */
[...]
#if APR_HAS_THREADS
if (mutex != NULL)
apr_thread_mutex_unlock(mutex);
#endif
All of those functions are public. So we should be able to do the same
thing ourselves. (The allocator mutex could be retrieved again in the
unlock code, so we could add svn_pool_lock() and svn_pool_unlock() to
svn_pools.h, although we might not want to do that in the 1.1 backport.)
That gives us a couple of options for storing xlate handles in parent
pools. We can either store bare xlate handles and lock around the
translation we do with them, or we can store <xlate handle, thread id>
pairs and just lock around the retrieval of the xlate handle, ensuring
that we never use a handle in more than one thread. I'm guessing the
latter will turn out to be easier to implement, although it's a little
harder to think about.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 15 16:49:54 2004