[Twisted-Python] Comparing "Stackless Python + Nonblocking Stackless Modules" with Twisted.

[Andrew Francis]

Hi Peter:

Message: 7
Date: Sun, 9 May 2010 23:24:00 +0800
From: Peter Cai <newptcai at gmail.com>
Subject: [Twisted-Python] Comparing "Stackless Python + Nonblocking
    Stackless Modules" with Twisted.
To: Twisted general discussion <twisted-python at twistedmatrix.com>
Message-ID:
    <o2ybefee6d81005090824l63d3f53fyc62a9d48f19093ac at 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