[Twisted-Python] PDF I thought may be of interest

[glyph at divmod.com]

On 10:06 pm, ms at cerenity.org wrote:
>Looking slightly below the surface of things, it appears to be 
>advocating
>something more like stackless's tasklets, rather than OS level threads 
>(since
>it makes reference near the end to Erlang's threading model).

Yes, and for this reason I found the paper to be somewhat disingenuous. 
It pops up every so often.

For one thing, it doesn't mention the extreme difficulty of writing 
correct threaded code that manages shared state.  There is a brief nod 
to this, where they say "Although static detection of race conditions is 
challenging"... then they go on to say maybe it's possible if you do 
some whole-program analysis, completely disregarding the unsuitability 
of whole-program analysis to long-lived, dynamic server systems 
(arguably the most popular choice for highly concurrent systems) which 
often require live, and therefore modular, updates.

Simplicity is Twisted's main advantage - obviously if we were 
performance-obsessed Python would be a poor choice for an implementation 
language, and all the paper really talks about is performance.  It's 
easier to write *correct* code in an event-driven model because 
everything that's happening is obvious once you understand what's going 
on.  I've often spotted concurrency problems in Twisted just in a code 
review.  In a threaded program, even if you're a threading expert, it's 
very very easy to miss subtle concurrency bugs.

For another, the paper arbitrarily redefines the word "threads" to mean 
"this cool thing that doesn't exist yet", rather than existing things 
that people call "threads".  It specifically mentions the deficiencies 
of current thread implementations and does not always point to specific 
improvements, let alone the challenge of popularizing and deploying 
those improvements.  The comparison to erlang's concurrency model is 
interesting, since they specifically avoid the term "threads" - erlang 
calls them "processes" to avoid exactly the confusion the authors are 
attempting to create.

So, in the fantasy world the authors have constructed, where threads are 
different than what we call "threads", they might be better than 
"events" for high-concurrency systems.  I'm probably even glad they 
chose the misleading, but controversial, title to draw attention to 
their work, because I think those ideas are interesting (if impractical) 
and I'm glad I read about them.