[MEGE] Fix some lock-related test failures (was Re: Testing and lock noise stipple.)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
>>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:
> 
> <snip/>
> 
>     >> test_break_lock: leaves the lock/unlock unbalanced on purpose
> 
>     jam> It leaves it unbalanced at the time of 'ld2.break_lock()'. And the
>     jam> ld1.unlock() raises an exception because the lock was broken. I would
>     jam> say that
> 
>     jam> 1) break_lock() might hint to the other lock that it is now balanced.
>     jam> 2) Add a 'ld1._rebalance_unlock()' sort of function that is used by the
>     jam> test suite under these conditions, to let the locking internals know
>     jam> that things are actually balanced again.
> 
> I went with adding a lock_broken hook and count the broken locks
> as released locks, this fixed that test and the following.

Seems like a reasonable way to go.

...

>     jam> This one is a bit more tricky, because we intentionally
>     jam> delete the lock object before we would have a chance to
>     jam> rebalance it. However, I don't think the test spirit
>     jam> actually requires that. It is really just testing that
>     jam> after breaking a lock, we can then obtain a new lock.
> 
> Indeed. And this one only missed a ld2.unlock() added to get
> fixed.

Well, that an needing your broken lock handler :).

> 
> <snip/>
> 
>     jam> I guess my argument is for some sort of
>     jam> LockObject._noop_unlock()...
> 
> I find the broken lock hook cleaner, so this is now a real
> submission.
> 
> Note that it reduces the failures from 70 to 31.
> 
> I fixed some more but the remaining ones are related to
> leave_lock_in_place and I need a bit more time to understand the
> logic here, I'll send another submission for them unless someone
> beat me to it.
> 
>         Vincent
> 
> 

I'm pretty sure 'leave_lock_in_place' is meant as a way to defer to
someone else to actually clean up the lock. And is meant to be used when
you are co-mingling stuff like a Smart lock verb with direct vfs actions.

So it will probably fall into 'yet another unlock' case, but I'm not
100% sure. Certainly I believe 'x.leave_lock_in_place(); x.unlock()' is
designed to *not* fix the physical lock, and the whole point is making
sure that eventually the physical disk locks are getting cleaned up.

Hmm.. thinking of it that way, it may be that 'leave_lock_in_place()'
should actually be considered as a 'lock' request...

John
=:->

BB:approve

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoEYysACgkQJdeBCYSNAAMlywCg0kD9SkdxPANOlCwxucikTg0w
auIAoJ571x2T0RvEskHOZC6bmdBNLVlg
=r0Vc
-----END PGP SIGNATURE-----