Re: svn commit: rev 3709 - in trunk/subversion: libsvn_wc libsvn_client

Philip Martin <philip@codematters.co.uk> writes:

> The thing that worries me, something I have just recently thought of,
> is that the parent pool could be the global pool. If that were the
> case all the thread-safety problems would reappear.

It doesn't have to be the global pool for this to be a threading
problem. A thread cannot, in general, assume that it can safely
access a parent pool, that only works if the thread has exclusive
access to the parent pool.

I'm not sure what to do here. We have gradually been moving away from
functions that allocate their own pools, to functions that use the
pools passed in to them. So svn_wc_adm_open creates an access baton
in the pool it is given. When the cleanup handler for the access
baton runs, it can choose to use either the pool it was given, or that
pool's parent pool, and at present neither appears to be correct.

Here's the best solution I can come up with: first we need an APR that
allows us to allocate from the pool during pool cleanup. Second we
revert to using the pool, rather than the parent pool, in cleanup
handlers. Finally, we change the Subversion access baton code, so
that it registers its cleanup handler later, in particular it must
register it *after* doing the first UTF8 conversion. This will ensure
that even if the access baton is responsible for creating the
apr_xlate_t object in the pool, the access baton cleanup handler will
run *before* the APR handler cleans-up the apr_xlate_t object.

I don't really understand the prohibition on allocating from a pool
during a cleanup handler, Subversion has been doing it for some time
and it doesn't appear to be a problem. I've had a quick look at the
APR pool code and I see no obvious reason for it not to work (but I
may well have missed something). So working on the assumption that it
is indeed OK, I made the other changes. FWIW, everything seems to
work, the regression tests pass.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org