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

Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Mon, 5 May 2014 01:19:05 +0200

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

> On Thu, Apr 24, 2014 at 11:55 AM, Philip Martin <
> philip.martin_at_wandisco.com> wrote:
>
>> Stefan Fuhrmann <stefan.fuhrmann_at_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.
Received on 2014-05-05 01:19:36 CEST

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