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

[Manlio Perillo]

glyph at divmod.com ha scritto:
> On 10:06 pm, ms at 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