> asyncore gives me a headache.
I think this is true for any value of "me" <0.5 wink>.
>> BTW, something that might help get more clues: ZEO does a
>> nasty thing to asyncore. In ZEO's
>> ThreadedAsync/LoopCallback.py, it reaches into Python's
>> asyncore module and _replaces_ asyncore.loop with its own
>> loop function. That shouldn't change the functionality of
>> asyncore, but it means that if you, e.g., put print
>> statements or debugger breakpoints in Python's asyncore loop,
>> they'll never trigger. If you're working at that level, you
>> need to put them in LoopCallback.py's functions instead.
Argh. This explains a lot. I couldn't understand why print statements in
asyncore.loop didn't print, unless I renamed loop and called the renamed
function (which would then have done bad things to ZEO, no doubt). Nasty
> If the flow is like this:
> asyncore mainloop invokes POP3 proxy code
> POP3 proxy code makes a synchronous ZEO call
> then I figure the app may well hang then: the thread running the
> asyncore mainloop is still running a POP3 proxy callback,
> waiting for a response that can never happen until the asyncore
> mainloop gets control back (in order to send & receive ZEO messages).
This was definitely the problem. The easiest solution (partly because some
of this work is already done <wink>), IMO, is to separate out the ZEO and
asyncore-based proxy into separate asyncore maps and have two asyncore
mainloop threads, one for each map. This follows Tim's comment about ZEO
expecting the asyncore loop to be in a separate thread, too.
Anyway, this appears to have fixed the problem. Many thanks for the clues -
you might not have understood why it was hanging, but your comments were
enough to get it fixed anyway :)
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org