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.
