[merge][#109520] gc of LockableFiles should not warn or unlock

Martin Pool mbp at canonical.com
Tue Apr 8 03:13:43 BST 2008


On Tue, Apr 8, 2008 at 6:29 AM, Robert Collins
<robertc at robertcollins.net> wrote:
>  > Now that we have a deterministic check during the test suite there
>  > seems even less reason to keep the gc warning.
>
>  Except that its at a different level: I've hooked in at the very lowest
>  level; possibly I should have hooked into LockableFiles instead; then
>  this would be a clear replacement for the gc warning. I went for the low
>  level locks rather than LockableFiles, because I understood you want to
>  reduce the dependence/use of lockable files.

I do, and I have a somewhat dusty patch that removes it.  I will try
to update it and merge it.  In fact, redoing lock leak debugging in a
better way and different place is one part of that done, so I feel
safe about removing this.

The thing is when something fundamental like the transport connection
fails or the process is interrupted, there are going to be some
objects that are not closed by a finally block but are closed by gc.
The physics of try/except handling means this is practically
unavoidable.

So I'm going to send my patch in too.

>  > (Robert said something about a long-running server possibly wanting to
>  > debug leaked locks - I would think that there too it probably should
>  > do something more like what the test suite does.)
>
>  Agreed here too - perhaps doing an analagous thing to what I did but for
>  LockableFiles should be done soon ?

Well, every LockableFiles used by a server except on ancient formats
will actually be using lockdirs so I think there's no difference in
practice.  We could put it a Lock base class, or maybe do similar
debugging for transactions.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list