win32 file locking

[Martin Pool]

On 25 May 2005, Andrew Bennetts <andrew at canonical.com> wrote:
> On Tue, May 24, 2005 at 10:37:29PM -0500, John A Meinel wrote:
> [...]
> > 
> > Also, I noticed that Branch() does not automatically unlock the lockfile
> > when it is done. Shouldn't that be done in the deconstructor?
> 
> __del__ should be avoided, particularly for releasing resources.  It may be
> called at arbitrary, unpredictable times by the interpreter -- if at all.

By design all of the references in bzrlib objects are "downwards", so
nothing there should cause a circular reference.  But I can't
guarantee that one won't arise through user code or some later change.

I think it's OK to use __del__ for such things as cleaning up
temporary files -- if __del__ is never called then we will just leave
some temporary files behind, which is tolerable.  Leaving something
locked is not acceptable.

> Just release resources explicitly.

The limitations of __del__ imply that RIAA will just never work well
in Python.

Rather than kludge this, I think we should just not make locks bound
to the lifetime of the Branch, but rather have explicit lock and
unlock methods, where the unlock should always be called from a
matching finally clause.  There can perhaps be a __del__ that gives a
warning.

(Maybe through the warnings module? http://www.python.org/peps/pep-0230.html)

Most callers of bzrlib should not need to lock the branch unless they
specifically want it to remain isolated across multiple calls.  So
commit will have an lock/unlock pair inside.  These should probably be
reentrant locks done in Python, so as not to worry (so much) about
whether OS locks are reentrant or not.

-- 
Martin