[Tim Peters] > asyncore gives me a headache. I think this is true for any value of "me" <0.5 wink>.
[Tim, later] >> 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 indeed :) > 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 :) =Tony.Meyer _______________________________________________ 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