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

Question

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.

Stoplight

You mean, aside from all of the other VMs mentioned in the article you link to? – Lyophilize

The article is about green threads. Erlang uses "green processes". The author wants to know what other systems use green processes. – Worth

Are Java Runnable objects scheduled in a ThreadPoolExecutor green processes? – Henson

Java doesn't use Green Threads anymore it was dropped years ago. – Fumigator

somewhat related: #1947680 – Stoplight

Haskell. #5848142 – Fitzwater

Answer 1

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.

Solidify

I didn't know that... but then again, there are so many things I do not know about :-) Thanks! – Stoplight

The term "Light-weight process" is more common for a "green process". en.wikipedia.org/wiki/Light-weight_process – Trisa

Answer 2

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).

Winchester

No shared state is very much a conceptual difference. – Solidify

why bother using different terms then? – Stoplight

How big the conceptual difference is depends on how used you are to shared-memory threads. I guess if you think it's very important because it makes concurrency easier, then you migh want to stress the difference by using different terms. Note though that the "green processes" term actually doesn't seem to be official. – Winchester

Answer 3

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

Firebrick

@Worth Conceptually, green threads and light-weight processes are same. – Cigarillo

@Vijay - they are not. Processes do not share state, threads do. 'green' processes do not share state, green threads do. – Sosanna

Answer 4

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

Nickerson