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

Re: EDEADLK in svn_repos_fs_begin_txn_for_commit2

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 26 Jan 2011 17:24:47 -0800

On 01/26/2011 11:39 AM, Blair Zajac wrote:
> On 01/26/2011 11:15 AM, Philip Martin wrote:
>> Blair Zajac<blair_at_orcaware.com> writes:
>>
>>> I'm now thinking of putting the retry in svn_io_file_lock2() instead
>>> of handling a deadlock in libsvn_fs_fs itself. It shouldn't hurt any
>>> other use cases and be a general, defensive code.
>>
>> Should retry be conditional on a threaded build? Can this problem even
>> occur in a non-threaded build?
>
> Good point. I think with svn's code, no, it wouldn't happen in a
> non-threaded build because the process does nothing else when it has the
> lock, it'll only ever have one lock out at a time.
>
> I was also going to have the code only retry if EDEADLK is defined, so
> it wouldn't retry on win32. The #ifdef EDEADLK could also include
> defined(APR_HAS_THREADS).

Fixed in r1063870 and r1063946.

Will nominate for backport to 1.6.x.

Blair
Received on 2011-01-27 02:25:27 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.