architecture - Erlang以外に「グリーンプロセス」に基づいているシステムは何ですか？

Question

Green Thread（Wikipedia）でこの有益なページを読んでいたのですが、Erlang以外に「グリーンプロセス」に依存しているプログラミングシステムは他にあるのでしょうか。

編集：「グリーンスレッド！=グリーンプロセス」

グリーンプロセスベース

• Erlang
• インフェルノ

グリーンスレッドベース

• 行け

ネイティブプロセスベース

• C、C ++

更新：誰も質問に直接回答しなかったため、グリーンプロセス全般に関する詳細情報を提供する回答を受け入れました。

Answer 1

名前としての「グリーンスレッド」全体については、この投稿のコメントを参照してください。

さらに深刻なことに、「ユーザースペース協調スレッド」のようなあまり冗談ではなく、Javaキャンプの用語を使用しているのを見て驚いています。ナイスガイのピーター・ファン・デル・リンデンがこの用語の由来を説明しています。

Java 1.0が最初にSolarisでリリースされたとき、スレッドをサポートするためにネイティブSolarisライブラリlibthread.soを使用していませんでした。代わりに、コードネーム「Green」の以前のプロジェクト用にJavaで記述されたランタイムスレッドサポートを使用しました。そのスレッドライブラリは「グリーンスレッド」として知られるようになりました。

代わりに、オペレーティングシステムの用語を使用できればと思います。たとえば、ユーザースペースとスレッドのカーネルスケジューリングなどです。結局のところ、これはオペレーティングシステムレベルの違いです。「グリーンスレッド」という名前は、Javaの歴史にすぎません。

Answer 2

私が理解しているように、これらの「グリーンプロセス」は、実際にはグリーンスレッドと根本的に違いはありません。共有状態の欠如は、技術的または大きな概念上の違いではなく、言語設計に起因します。Erlangは単純に：

• 複数のプロセスからアクセスできるようなグローバル変数はありません
• 明示的なメッセージを介してのみプロセス間の通信を許可します
• メッセージパラメータを暗黙的にコピーします（この手法の大きな欠点）

したがって、2つのプロセスがOSレベルで仮想メモリを共有している場合でも、2つのプロセスが同じメモリにアクセスする方法はありません（これにより、OSレベルのスレッドがないアーキテクチャでErlangを実装しやすくなります）。

Answer 3

Javaは1.2までそれらを使用していました。それから彼らは2回スケジュールされたより軽いスレッドを持つことはそれほど効率的ではないことに気づきました。

Answer 4

現在、N：Mスレッド用のモジュールとカーネルスレッド用のモジュールを備えたRust（rust-lang.orgを参照）もあります。