問題タブ [green-threads]

イベントレットですべてにモンキーパッチを適用したDjango/Tastypieアプリがあります。

gunicorn の sync ワーカー クラスと eventlet ワーカー クラスの両方を使用して、負荷テスト中のパフォーマンスを分析しました。他の greenthreads が元に戻るのを待つことによる影響を排除するために、sync worker に対してテストを行ったところ、スロットリング コード内の memcached 呼び出しは、単独で約 1 ミリ秒しかかからないことがわかりました。この 1 ミリ秒の応答を待っている間に別のグリーンスレッドに切り替えるのではなく、この時点でブロックするだけです。eventlet に別のグリーンスレッドに切り替えないように指示する方法はありますか? 多分コンテキストマネージャーか何か？

M:NRust でスレッド モデル を使用するには、プールを開始し、通常どおりタスクの生成を開始します。Green Documentationには、次の例が示されています。

別の OS スレッドを動的に追加したい場合は、次のようにします。

x num の OS スレッドを使用する方法はありますか、それともコード内で作成および管理する必要がありますか?

私の Python プログラムでは、eventlet を使用して多くの greenthreads を作成しています。現在の greenthread がスリープしているかどうか、残りのどれがスケジュールされて実行されるかを知りたいだけです。イベントレットにスケジューラはありますか?

ありがとう！

ネイティブ コード ジェネレーターとして LLVM を使用する Erlang の流れで、軽量プロセス (「グリーン スレッド」) をサポートする並行言語の設計を検討しています。軽量プロセスは M:N 方式でネイティブ OS スレッドに割り当てられ、スレッド間のワークスティーリングが可能である必要があります (つまり、プロセスは、必要に応じてスレッド間で受け渡しできるデータ構造によって表される必要があります)。非常に多数のプロセスが同時に存在する可能性があるため、プロセスは多くのメモリを消費せず、プロセス間のコンテキストの切り替えはできるだけ迅速に行う必要があります。さらに、コンテキストの切り替え中またはガベージ コレクションが発生した場合に、軽量プロセスを "一時停止" するのはかなり簡単なはずです。Erlang に LLVM バックエンドがあることは理解していますが、その実装に関する文献はほとんど見つかりません。

すべてのリクエストがユーザー レベル スレッド (ULT) (グリーン スレッド/erlang プロセス/ゴルーチン/... 任意の軽量スレッド) によって処理されるプラットフォームで Web アプリを構築することを検討してください。すべてのリクエストがステートレスであり、アプリの起動時に DB 接続などのリソースが取得され、これらのスレッド間で共有されると仮定します。これらのスレッドでのガベージ コレクションの必要性は何ですか?

一般に、このようなスレッドは実行時間が短く (数ミリ秒)、適切に設計されていれば、数 (KB または MB) 以上のメモリを使用しません。スレッドに割り当てられたリソースのガベージ コレクションがスレッドの終了時に実行され、他のスレッドから独立している場合、リクエストの 98 パーセンタイルまたは 99 パーセンタイルでも GC の一時停止は発生しません。すべての要求は、予測可能な時間内に回答されます。

このようなモデルの問題点は何ですか? また、広く使用されていないのはなぜですか?

ランタイムの自由: Rust のランタイム システムとグリーン スレッド モデルは完全に削除され、「hello world」の静的バイナリ サイズが半分になり、標準ライブラリへの低レベル フックへの扉が開かれました。Aaron Turon によって実装されました。

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

グリーン スレッド モデルの欠点は何ですか?

なぜErlangは速いのですか?

http://eventlet.net/doc/patching.htmのドキュメントに は、「引数が指定されていない場合、すべてにパッチが適用されます」と記載されています。および「スレッド、スレッド、およびキューにパッチを適用するスレッド」。

しかし、簡単なテストでは:

結果は次のとおりです。

スレッドにはまったくパッチが適用されていないようです。ドキュメントが間違っていますか？

このコードは何も出力しません:

しかし、このコードは数字を出力します:

唯一の違いはpool.waitall(). 私の考えでwaitall()は、プール内のすべてのグリーンスレッドが機能し終わるまで待機することを意味しますが、無限ループはすべてのグリーンスレッドを待機するため、pool.waitall()必要ありません。

では、なぜこれが起こるのですか？

参照: http://eventlet.net/doc/modules/greenpool.html#eventlet.greenpool.GreenPool.waitall