threads and the working copy

[Andy Cutright <An...@borland.com>]

hi all,

i'm curious about whether the 1.2 client libraries are thread safe. more
specifically, is it safe to modify a single working copy concurrently
using the client libraries? is it supported for example to run two or
more concurrent commits on different files or hierarchies using the same
working copy? clearly, i'm not expecting to modify a single file on two
different threads. also, is the javahl library thread safe? 

i've taken a look at the documentation (but not much at the code
unfortunately) and don't see much mention about concurrency issues. 

along the same lines, i've seen discussion about issues with FSFS and
the APR on UNIX. 

http://subversion.tigris.org/issues/show_bug.cgi?id=2265

the bug report says this is "largely fixed". what are the remaining
issues in 1.2? 

cheers,
andy 

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

Re: threads and the working copy

[Greg Hudson <gh...@MIT.EDU>]

On Mon, 2005-06-20 at 12:53 -0700, Andy Cutright wrote:
> i'm curious about whether the 1.2 client libraries are thread safe. more
> specifically, is it safe to modify a single working copy concurrently
> using the client libraries? is it supported for example to run two or
> more concurrent commits on different files or hierarchies using the same
> working copy?

It's basically safe as far as I know.  If you use ra_dav, neon's
initialization is protected by a static variable, which means there's an
unlikely race condition there.

> along the same lines, i've seen discussion about issues with FSFS and
> the APR on UNIX. 

> http://subversion.tigris.org/issues/show_bug.cgi?id=2265
> 
> the bug report says this is "largely fixed". what are the remaining
> issues in 1.2? 

If the caller changes the uuid of a repository using svn_fs_set_uuid()
and, without closing that repository, opens it within another thread,
two different mutexes will be used the protect the write lock within the
repository, which means both threads might consider themselves to be
holding the write lock at the same time, which could lead to colliding
commits.

The only real-life consumer of svn_fs_set_uuid() is "svnadmin load",
which is not multi-threaded, so this is not a practical issue.


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