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.
Blair
Received on 2011-02-01 20:53:42 CET