Stackless Python に関連する多くの質問があります。しかし、この私の質問に答えている人は誰もいないと思います（間違っている場合は修正してください-お願いします！）。いつも話題になっているので知りたいです。スタックレスを何に使用しますか? CPythonよりも優れている点は?
はい、操作がブロックされていない限り、多くの軽量スレッドをすばやく作成できるグリーン スレッド (スタックレス) があります (Ruby のスレッドのようなものですか?)。これは何に最適ですか？CPython で使用したい他の機能はありますか?
これにより、大量の同時実行を処理できます。10 万のシステム スレッドを作成する正気な人はいませんが、スタックレスを使用してこれを行うことができます。
この記事では、Python と Google Go (新しいプログラミング言語) の両方で 10 万個のタスクレットを作成して、まさにそれをテストします。
驚くべきことに、たとえ Google Go がネイティブ コードにコンパイルされていて、彼らがコルーチンの実装を宣伝しているとしても、依然として Python が勝っています。
スタックレスは、入力データに応じて非常に多数のレデューサーを使用できるマップ/リデュース アルゴリズムの実装に適しています。
スタックレス Python の主な利点は、非常に軽量なコルーチンのサポートです。CPython はネイティブでコルーチンをサポートしていません (ただし、誰かがジェネレーター ベースのハックをコメントに投稿することを期待しています)。そのため、コルーチンの恩恵を受ける問題がある場合、Stackless は CPython の明らかな改善点です。
それらが優れている主な領域は、プログラム内で多くの同時タスクが実行されている場合だと思います。例としては、AI のループ スクリプトを実行するゲーム エンティティや、ページの作成が遅い多くのクライアントにサービスを提供している Web サーバーなどがあります。
同時実行の正確性に関する典型的な問題の多くはまだありますが、共有データに関しては、決定論的なタスクの切り替えにより、制御が転送される場所が正確にわかっているため、安全なコードを簡単に記述できます。したがって、共有状態が必要な正確なポイントがわかります。最新の。
サーラーは、Eve Online でスタックレスが使用されたことを既に述べました。それを念頭に置いて：
(..) スタックレスは、タスクをより小さなタスク (タスクレット) に分割できるようにすることで、これにさらにひねりを加えます。タスクレットは、メイン プログラムから分割して独自に実行できます。これは、電子メールの送信やイベントのディスパッチなどのファイア アンド フォーゲット タスクや、ネットワーク パケットの送受信などの IO 操作に使用できます。1 つのタスクレットがネットワークからのパケットを待機している間、他のタスクレットはゲーム ループの実行を続けます。
いくつかの点でスレッドに似ていますが、プリエンプティブではなく、明示的にスケジュールされるため、同期に関する問題は少なくなります。また、タスクレット間の切り替えは、スレッドの切り替えよりもはるかに高速であり、コンピューター ハードウェアによってスレッドの数が厳しく制限されているにもかかわらず、膨大な数のアクティブなタスクレットを持つことができます。
（この引用はここから入手）
PyCon 2009 では、CCP Games で Stackless が使用される理由と方法について説明する非常に興味深い講演が行われました。
また、非常に優れた入門資料があり、スタックレスがアプリケーションにとって優れたソリューションである理由を説明しています。（少し古いかもしれませんが、読む価値はあると思います）。
EVEOnline は、大部分が Stackless Python でプログラムされています。彼らは、その使用に関するいくつかの開発ブログを持っています。ハイ パフォーマンス コンピューティングに非常に役立つようです。
私は Stackless 自体を使用したことはありませんが、同時実行性の高いネットワーク アプリケーションを実装するために Greenlet を使用しました。Linden Lab が対象としているユース ケースには、高性能スマート プロキシ、膨大な数のマシンにコマンドを分散するための高速システム、大量のデータベースの書き込みと読み取り (約 1 の比率) を実行するアプリケーションなどがあります。 :2、これは非常に書き込みが多いため、データベースが戻るのを待つことにほとんどの時間を費やしています)、および内部 Web データ用の web-crawler-type-thing です。基本的に、多くのネットワーク I/O を実行する必要があると予想されるアプリは、膨大な数の軽量スレッドを作成できることから恩恵を受けます。10,000 の接続されたクライアントは、私には大したことではないように思えます。
ただし、Stackless または Greenlet は実際には完全なソリューションではありません。それらは非常に低レベルであり、それらを最大限に活用するアプリケーションを構築するには、多くのサルワークを行う必要があります。私がこれを知っているのは、Greenlet の上にネットワーキングおよびスケジューリング レイヤーを提供するライブラリを維持しているからです。具体的には、アプリケーションの作成が非常に簡単だからです。現在、これらはたくさんあります。私は Eventlet を維持していますが、Concurrence、Chiral、そしておそらく私が知らないいくつかのものもあります。
作成したいアプリの種類が、私が書いたものと似ている場合は、これらのライブラリのいずれかを検討してください。Stackless と Greenlet のどちらを選択するかは、目的のニーズに最適なライブラリを決定することほど重要ではありません。
私が考えるグリーン スレッドの基本的な有用性は、待ち時間の長い操作を行うオブジェクトが大量にあるシステムを実装することです。具体的な例は、他のマシンとの通信です。
def Run():
# Do stuff
request_information() # This call might block
# Proceed doing more stuff
スレッドを使用すると、上記のコードを自然に記述できますが、オブジェクトの数が十分に多い場合、スレッドは適切に実行できません。しかし、非常に大量の場合でも、グリーン スレッドを使用できます。上記request_information()は、他の作業が待機しているスケジューラーに切り替わり、後で戻る可能性があります。スレッドを使用せずにすぐに返されるかのように、 「ブロッキング」関数を呼び出すことができるというすべての利点が得られます。
これは、単純な方法でコードを書きたい場合、あらゆる種類の分散コンピューティングで明らかに非常に役立ちます。
複数のコアがロックの待機を軽減することも興味深いです。
def Run():
# Do some calculations
green_lock(the_foo)
# Do some more calculations
関数は基本的にgreen_lockロックを取得しようとし、オブジェクトを使用している他のコアが原因で失敗した場合はメイン スケジューラに切り替えます。
繰り返しになりますが、グリーン スレッドを使用してブロックを軽減し、コードを自然に記述してパフォーマンスを向上させることができます。