On 2/1/11 11:53 AM, Blair Zajac wrote:
> 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
...was the right move.
Blair
Received on 2011-02-01 21:03:31 CET