Build failure on xenial

[Matt Mackall]

On Wed, 2016-06-01 at 14:21 -0700, Sean Farley wrote:
> Got another failure, this time with locking:
> 
> cd tests && python run-tests.py -j4
> sss...s...s..s..ss.s..ss.ss..s...s...s......sss..s.......s..s...s.
> --- /«BUILDDIR»/mercurial-3.8.2+208-trusty/tests/test-clone.t
> +++ /«BUILDDIR»/mercurial-3.8.2+208-trusty/tests/test-clone.t.err
> @@ -1075,8 +1075,6 @@
>  
>    $ cat race2.log
>    (sharing from existing pooled repository
> b5f04eac9d8f7a6a9fcb070243cccea7dc5ea0c1)
> -  waiting for lock on repository share-destrace2 held by * (glob)
> -  got lock after \d+ seconds (re)
>    searching for changes
>    no changes found
>    adding remote bookmark bookA

Yep, due to load on your build host, this test has run over the internal lock
delays and released the lock.

In other tests of this sort, we use hook tricks to actually reliably stop the
racing task in the middle so that we can guarantee the race happens (and let us
get rid of test-suite-slowing sleeps).

Here perhaps we could do that by having the lockdelay extension stop itself
after lock acquisition and the kick the locking task on contention.

-- 
Mathematics is the supreme nostalgia of our time.