gl...@divmod.com ha scritto:
On 10:06 pm, m...@cerenity.org wrote:
[...]
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.
The reason Erlang calls them "processes" is because in Erlang each
"thread of execution" share nothings with other "threads of execution".
Haskell, as an example, has "micro threads" support, and it calls them
threads (or "Haskell threads"), since the state is shared (but the
function that creates a new "thread" is called forkIO, with an
additional function forkOS, that creates a thread bound to an OS thread).
Haskell also have nice synchronization support, MVar and Chan (with
equivalent functions based on STM).
Something similar is found in Stackless Python.
As a final note, there is an interesting paper:
http://www.cis.upenn.edu/~lipeng/homepage/unify.html
Regards Manlio Perillo
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
