On Tue, Apr 29, 2014 at 1:24 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:

> On Thu, Apr 24, 2014 at 11:55 AM, Philip Martin <
> philip.mar...@wandisco.com> wrote:
>
>> Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes:
>>
>> > Since no functionality depended on the change so far, except
>> > for some extra fool-proving during hotcopy, I reverted the change
>> > in r1589518.
>>
>> svnadmin_tests.py 40 started to take advantage of your change and would
>> hang after you reverted it.  The problem was
>>
>>    svnadmin create repo1
>>    svnadmin hotcopy repo1 repo2
>>    echo repo1 > repos
>>    echo repo2 >> repos
>>    svnadmin freeze -F repos true
>>
>
> I'm aware of that problem. It should already be present in 1.8.x.
> But my original patch clearly broke our locking guarantees in
> some not-so-obvious-to-the-user cases, so it had to be reverted.
>
> I've changed the hotcopy UUID to avoid the hang.  Could FSFS detect the
>> deadlock and return an error rather than hang?
>>
>
> If we allow for some false negatives, then yes. We could store
> the thread ID alongside the lock and test that before attempting
> to acquire it. This mechanism would need to be FSFS-internal
> only as it is unclear whether we would allow for the unknown
> overhead in all places that use svn_mutex__t.
>
> -- Stefan^2.
>

So, r1591872 adds a very small overhead to all uses of svn_mutex__t
but for that we get optional recursion everywhere.

-- Stefan^2.

Reply via email to