What other systems beside Erlang are based on "Green Processes"?

907 views Asked by At

I was reading this informative page on Green Thread (Wikipedia) and I wonder: what other programming systems rely on "green processes" beside Erlang?

Edit: " Green Thread != Green Process "

Green Process based

  • Erlang
  • Inferno

Green Thread based

  • Go

Native Process based

  • C, C++

Updated: Nobody answered the question directly and so I have accepted an answer that provided me with more information with regards to Green Processes in general.

4

There are 4 answers

2
Christian On BEST ANSWER

Regarding the whole "green thread" as a name, see comments on this post:

More seriously, I'm surprised to see you using a term from the Java camp, instead of something less jargony like "user-space cooperative threading"; nice guy Peter van der Linden explains the origin of the term:

When Java 1.0 first came out on Solaris, it did not use the native Solaris library libthread.so to support threads. Instead it used runtime thread support that had been written in Java for an earlier project code-named "Green." That thread library came to be known as "green threads."

I wish we could use the terminology from operating systems instead, e.g. user-space vs kernel scheduling of threads. After all, it is an operating system level distinction. The name "green thread" is only Java history.

2
Jack On

Java used them until 1.2.. then they realized that having a lighter thread that is scheduled twice wasn't so efficient.

3
Michael Borgwardt On

As I understand it, these "green processes" are in fact not fundamentally different from green threads. The lack of shared state results from the language design, not from any technolgical or huge conceptual difference. Erlang simply:

  • Does not have any kind of global variables that would be accessible from multiple processes
  • Allows communication between processes only through explicit messages
  • Implicitly copies message parameters (the big drawback of this technique)

Thus, there is no way for two processes to access the same memory, even though they might have shared virtual memory on the OS level (which I guess makes Erlang easier to implement on architectures that don't have OS-level threads).

0
OlliP On

Now, there is also Rust (see rust-lang.org) which has a module for N:M threads and one for kernel threads.