[ZODB-Dev] Tracking down a freeze (deadlock?)

[Florent Guillaume]

Tim Peters wrote:
>>I do not think that "__del__" (at least with its current semantics) is
>>useful for persistent classes.
>>
>>The only use case I can think of is to clean up non-persistent resources
>>associated with the instance. However, the corresponding attributes (they
>>need to be volatile) are usually already lost when the "__del__" is
>>called (by a preceeding invalidation).
> 
> If it's desired to clean up a resource whenever a volatile attribute goes
> away, then a clean way to do that is to bind the volatile attribute to an
> instance of a simple non-persistent class where the *latter* has a __del__
> method, and where the latter class's only purpose in life is to clean up a
> resource via its __del__.  That's the best way to do
> resource-cleanup-via-__del__ in the absence of persistence too (then, for a
> start, instances of "the real" class don't have a __del__ method at all, so
> are immune to getting in trouble with cyclic gc).

For the archives, that's what's done for instance in 
CMFCore/MemberDataTool.py using CleanupTemp. It uses BaseRequest's _held 
variable that is destroyed when the request is destroyed (closed).

[...]
> Maybe even other of Florent's code:  he didn't say he thought it was dubious
> for a persistent object to *have* a __del__ method, just that it was dubious
> for the __del__ method to try to do ZODB operations.

Well actually I doubt the __del__ method would receive a wrapped self 
anyway, and that's a big part of why I thought that code was dubious.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com