win32 file locking
John A Meinel
john at arbash-meinel.com
Wed May 25 07:36:05 BST 2005
Andrew Bennetts wrote:
>On Wed, May 25, 2005 at 12:49:38AM -0500, John A Meinel wrote:
>>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
>The problem with adding a __del__ just-in-case is that it's usually a poor
>tradeoff -- in exchange for having a cleanup that might (but might not, so
>you can't rely on it) trigger when you forget, you also get the possibility
>of memory leaks.
>There's a compromise that might be helpful. Twisted recently removed the
>__del__ method on its Deferred objects, and instead moved the __del__ into a
>sub-object that unless someone is being naughty, should never be in a
>cycle by virtue of never being referenced from anywhere by the Deferred.
But it doesn't matter because the parent still holds a reference to the
DebugInfo, and if the parent is in a cycle, then it will never be
cleaned up, which means that self._debugInfo will also never be cleaned up.
I don't have a problem doing 'print a warning if not cleaned up' rather
than closing. Though I would also argue that you should cleanup anyway.
But we can make it a warning/error so that the bug gets fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050525/9089d814/attachment.pgp
More information about the bazaar