On 10:06 pm, [EMAIL PROTECTED] 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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
