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

[Tim Peters]

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

[Jim Fulton]
> Right. This is probably a good reason not to support __del__.

And it goes to the issue of bizarre semantics, it's not just about the
current implementation:  a persistent object P with a __del__ method
referencing an attribute of self necessarily resurrects and re-populates P
whenever P gets ghostified.  This combination just doesn't make good sense
on the face of it.

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

When there's a good semantic reason to use an RLock, I'm happy to use
Python's and wait for Python to improve its RLock implementation.  Win32 and
current POSIX pthreads both support reentrant locks natively.  Python's Lock
goes out of its way on Win32 to make it look non-reentrant.  Wrapping
another layer of C code around it (to make a reentrant lock wrapped in C
code to make it look non-reentrant look reentrant again <wink>) isn't a good
approach for the language.  The synch objects supplied by threading.py are
deliberately returned by factory functions (instead of being classes)
precisely so better platform-specific implementations can be provided in
compatible ways.  IIRC, there are even Python patches waiting on SourceForge
to do this, at least for Windows.