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.
