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

[Tim Peters]

[Tim Peters]
>> Why is that?  As far as I'm concerned, ZODB doesn't support persistent
>> objects with __del__ methods -- it was never intended to.

[Jim Fulton]
> I'm not aware of any specific decision not to support __del__.

I'm not aware of a specific decision either way.  Since the semantics of
__del__ with persistent objects are unclear, there's no specific decision
visible anywhere _to_ support them either, and people trying anyway provoke
bugs, "as far as I'm concerned" the combination isn't supported.

Note that a persistent object with a __del__ method referencing an attribute
of self is immortal (stays in a Connection's cache forever); that's the
price we paid for stopping the pickle cache from going into an infinite loop
on one of these things (and that this is so was advertised in the ZODB NEWS
file).
 
> I agree with Dieter that if we make such a decision, we should go out
> of our way to advertize, and perhaps, enforce it.

Or to support it.

> Are reentrant locks really all that expensive?  If so, why?

Lock.acquire() and Lock.release() are coded in C, talking directly to the
platform's C-level lock implementation; RLock.acquire() and RLock.release()
are coded in Python, and aren't even leaf-level Python functions.  I expect
Dieter is right that in this specific context it wouldn't matter enough to
care about; it can matter in high-contention contexts.