[Martin Gfeller, attacks a ZEO hang on Windows]
> ...
Man, that sucks! Looks like a Python bug to me, probably specific to
Windows, and (as you discovered) introduced in Python 2.4, but
deliberately not backported to 2.3. I opened a Python tracker item
with a minimal hanging test case:
http://www.python.org/sf/1473760
> ...
> My code uses no threads, apart from those created by ZEO itself.
A thread is needed to provoke an import hang, but ZEO creates quite
enough threads all by itself. "This kind of thing" generally requires
that a thread get spawned as a _side effect_ of doing an import(*),
but offhand I don't recall any code in ZODB/ZEO that does that. If
that rings a bell for anyone else, that would be an approach to
worming around the bug in the ZODB/ZEO code.
It's curious that nobody else reported this before, and ZODB's test
suite certainly doesn't provoke it (that's been run under Python 2.4
since before 2.4a1).
(*) Python's internal import lock is reentrant wrt the thread currently
doing an import, but blocks other threads from doing an import.
So the usual fatal dance starts like so:
thread A does an import of module M
code in module M spawns another thread B, and starts B running
code in thread B tries to do an import, but is blocked because
thread A's import (of M) is still in progress
thread A continues the process of importing M, and M does
something that waits for thread B to accomplish something
There the whole shebang deadlocks: A is waiting for B to do something,
and the import of M can't complete until A makes progress. But B
is waiting for the import of M to complete.
Hmm. I suppose there's some way for asyncore running in its own
thread to fatally confuse the import lock too, but I haven't bumped
into that myself.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
