win32 file locking

[John Arbash Meinel]

Martin Pool wrote:

>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.
>
>
>
Well, you still need an OS lock so that more than one process doesn't do
bad stuff to your tree. But I would say we can have the lock be *part*
of the branch object, just not locked upon creation/destruction. The
Branch object can keep track of whether or not it is locked.
If one of it's functions requires the lock, it can check and acquire the
lock (since we will be careful with try/finally). And we can easily do
refcounting on the lock to make sure it is properly re-entrant.

I still think a singleton is correct for handling each branch. You could
do it with a normal function Branch()/find_branch which looks it up in
the local dictionary, and returns the appropriate object. You wouldn't
have to use a proxy object.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050526/4d859c97/attachment.pgp