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

[Jim Fulton]

Tim Peters wrote:
> [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).

Right. This is probably a good reason not to support __del__.

> 
>>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.

We have a C reentrant lock implementation.  Maybe we should dust that off
and use it in ZODB, as we once did.  For that matter, I'd be happy
to contribute it to Python, if it makes sense to.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org