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

[Jim Fulton]

Tim Peters wrote:
> [Dieter]
> 
>>>I think both of them should get a warning: do not use "__del__".
> 
> 
> [Jim]
> 
>>Agreed. Let's smeone add this to the rules of persistence.
> 
> 
> As later msgs in this thread explained, a warning against using __del__ was
> added to the ZODB/ZEO Programming Guide 14 months ago, but only to the ZODB
> 3.3 version of the docs.  That _is_ the version visible on zope.org, though.
> Or are "the rules of persistence" documented in some place other than that
> (if so, where?)?

I have no idea.

> I'm currently:   writing more words about that; backporting the __del__
> verbiage to the 3.2 line (so the PDF we ship with ZODB 3.2.6 will contain
> it); updating the generated HTML on zope.org with the new words.

Cool.

> 
>>BTW, I ran into a similar problem when working on fixing ZClassesd for
>>2.8.  I change the way invalidations are handled in a way that will
>>probably fix this problem. :)
> 
> 
> Unclear which problem "this problem" means.  Changing the way invalidations
> work can't prevent all __del__-caused problems.  We still don't have a test
> case that provokes Florent's deadlock problem, BTW (and I still don't intend
> to spend time trying to create one).

In earlier messages, It looked like someone tracked down the deadlock
to a __del__ causing an object to get loaded when an object was
invalidated.  (An object was invalidated, which caused another object's
refcount to fall to 0, which caused it's __del__ to be called.  The
__del__ caused some object to be reloaded, which called setstate on the
connection.  The setstate tried to get the invalidation lock, which was
already held by the code doing the invalidation.)

This is very similar to the problem I ran into with ZClasses. When a ZClass
is invalidated, we want to reload the state.  Originally, this lead to a
deadlock.  I had to change some the invalidation strategy so that the code
the code that performes invalidations doesn't hold the invalidation lock.

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