Hi Peter: Message: 7 Date: Sun, 9 May 2010 23:24:00 +0800 From: Peter Cai <newptcai@gmail.com> Subject: [Twisted-Python] Comparing "Stackless Python + Nonblocking Stackless Modules" with Twisted. To: Twisted general discussion <twisted-python@twistedmatrix.com> Message-ID: <o2ybefee6d81005090824l63d3f53fyc62a9d48f19093ac@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

Today, a guy gave me an URL http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules

....

With this module and stackless python, theoretically, we can build a high concurrency network application framework which has a programming style close to traditional multi-thread module.

Drop the theoretical part.

The guy who gave me that URL asked a question, "Which style is better? The Twited's event-driven style or the imaginary one?"

What do you think about it? Of course, twisted is an mature framework we can trust, but doesn't the imaginary one also have pros?

Well stackless python with an asynchronous networking package is not an imaginary style. Lots of people are using this to great effect (i.e., EVE-Online)- I'll argue the underlying design pattern is based on Doug Schmitt's half-sync half-async" pattern. The idea of the stacklesssocket module is to act as a plug in replacement for the various networking packages one may use. Most of the time, things work. However I feel there are a few gotchas that one has to be aware of. Myself, I use Stackless with Twisted. Outside of a hiccup in the later versions (I think I need to set recursion depth for some weird reason), I am happy. I like the one-stop big box shopping I get from using Twisted. That said, I think for simple network interactions - that is programmes that interact with a single end-point, Twisted is perfectly fine. For that matter, even if one interacts with multiple end-points in parallel, Twisted is fine - use a deferredlist. Most programmes fall into this category. I think things get more complex when one is dealing with multiple end-points in sequence (now callbacks are chained) or one is using iterators (cooperators/coiterators now needed?). What light-weight threads do is make things synchronous and make the control flow obvious to the programmer (because one is relying on Python to provide the control flow). For better or worse, I do stuff pertaining to process orchestration and it is just out there at times. Cheers, Andrew