win32 file locking
John A Meinel
john at arbash-meinel.com
Wed May 25 06:49:38 BST 2005
Andrew Bennetts 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.
>In particular, if an object with a __del__ is in an unreachable reference
>cycle, the CPython garbage collector will just append the entire cycle to
>gc.garbage rather than try to figure out how on earth to deallocate it
>(there are periodic discussions of this limitation on python-dev, e.g.
>So __del__ tends to lead to memory leaks and objects *not* being released.
>Even if they do get released, it can happen much later than you expect,
>depending on when the garbage collector decides to look at that object.
>Just release resources explicitly.
>A quick grep shows me that bzr currently only uses __del__ in two places,
>and only in test code. I recommend keeping it that way.
I agree that resources should be released explicitly, that is what
.commit() is for. But in the case that there is an exception that wasn't
caught properly, it seems prudent to have the resource cleaned up
I suppose the alternative is to wrap your AtomicFile in a try: finally:
block. That takes more effort, and is easy to leak resources accidentally.
Take your pick. I'll probably always try to do the try/finally. And it
is probably the recommended method since that does force the release of
resources. But that doesn't mean having __del__ around as a cleanup is a
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050525/af70fec8/attachment.pgp
More information about the bazaar