Hi Don: [Don quote] Thanks to all the good folks who replied to this; good stuff to chew on. I particularly liked glyph's advice on when and where to use the inline callback style, and when/where to avoid it. I think I'll continue along the path I described, at least for a while. I may be back with more on this topic. ~ I saw your post but didn't have time to respond earlier.... I second Glyph's advice concerning inlineCallbacks.... I am building a WS-BPEL processor. WS-BPEL is about business logic and exotic message exchange patterns. I gave a talk at PyCon 2008 called "Adventures in Stackless Python Twisted Integration." My strategy is to separate the business logic as much as possible from the underlying networking. At the lower levels, I use Stackless Python in conjunction with Twisted. A side-effect of this approach is that I can block waiting for a Twisted call to finish. Right now, I am simplifying one of my prototypes so I can post it as a full-blown example of all the techniques I use. Give me a few days. To add to what others have said, the main problem I have encountered boil down to identifying classic concurrency problems. Unfortunately APIs and transitivity obscure bugs. I know this sounds obvious but no matter which concurrency model you use: event, pre-emptive threads, cooperate, you really have to understand how problems like say, deadlock and race conditions manifest themselves and take precautions. In the narrow field of Stackless and Twisted, I am trying to map out what those precautions are. Cheers, Andrew ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ