[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: Tue, 01 Feb 2011 11:53:02 -0800

On 1/26/11 5:24 PM, Blair Zajac wrote:
> 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.

We've now seen the same deadlock on the "db/write-lock" file during a commit, so
putting the retry in svn_io_file_lock2() was the

The only question left if we should retry on an EINTR? It appears that nobody
has seen this in practice, because we have have coded for it.

Received on 2011-02-01 20:53:42 CET

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