Python threading?

[Robert Oschler]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:MyUj9.134183$ub2.2937335 at news1.tin.it...
> Mark Hammond wrote:
>         ...
<snip>

> Python may not yet support event-driven programming quite as smoothly
> and seamlessly as Ousterhout's Tcl, but, thanks to such developments
> as twisted, I think we're drawing progressively closer.  With a solid
> enough underlying framework to dispatch events for you, I think event
> driven programming (perhaps with a few simple specialized threads off
> to one side, interfacing to some slow external resource, and getting
> work requests off a Queue, posting results back to a Queue...) can
> be made conceptually simpler as well as more scalable than threading.
> After all, in event-driven / async programming, ONE thing is happening
> at a time -- you only "switch" at known points, and between two such
> points you need not worry about what is or isn't atomic, locking, &c.
> It's also easier to debug, I think...
>
>

Having written _many_ state machines in my life, which async programming
boils down to in one form or another, I feel it depends on the task.  When
you have an async event driven model, the code that services a
"transaction-package" ends up spreading functionality that services the
"transaction-package" application's code landscape.  This can frequently be
a headache.  As an example of a "transaction-package", take all the steps
involved in servicing an incoming TCP connection, with custom authentication
of a user, and perhaps a header and data object transacttion or two,
finishing with a proper ending and cleanup of the transaction, and with
subsequent notification of all necessary modules and data structures of the
results of the transaction.  For dessert add a centralized clean error
handler that can log errors propertly and gracefully recover the app
regardless of where in the distributed event flow the error took place.

Contrast this with a simple procedure call where a linear series of function
calls are made, each with appropriate error handling and status adjustment,
in a pleasant centrally located manner.

There is an upcoming massively multiplayer game called EVE which is using
Stackless Python which makes this point quite well.  Game AI suffers from
the same design considerations as mentioned above.  Here's the link if
you're interested (I'm not associated with them in any way, just considering
taking a look at Stackless).  Look for question "8.5 How is the game logic
implemented in EVE?":

http://www.eve-online.com/faq/faq_08.asp

thx