Pythonのジェネレータは、一時停止したフレームオブジェクト（PyFrameObject）として実装されており、呼び出し間で実行状態を保持します。send(value)が呼ばれると、CPythonの内部関数gen_send_ex()がこの値をジェネレータの値スタックにプッシュし、yield式がそれをポップして呼び出し元に返します。これは、最初のnext()呼び出しとは異なり、最初の状態（f_lasti == -1）から最初のyield式までジェネレータをプライミングするために、暗黙的にNoneを送信します。ジェネレータが最初のyieldを行う前に非None値でsend()が呼ばれると、CPythonはTypeErrorを発生させます。なぜなら、ジェネレータフレームには値を受け取るスタック位置がないからです。このアーキテクチャ的区別は、ジェネレータが最初の一時停止ポイントに到達した後にのみ双方向通信が始まることを保証します。
高頻度の市場データフィードを処理するためのバックプレッシャーに注意したデータパイプラインを実装する必要がありました。下流の消費者が上流のプロデューサーにデータフローを制限または再開するように動的に信号を送ることができ、メッセージを失うことなくメモリを使い果たさないようにする必要がありました。
考慮されたアプローチの一つは、パイプラインのステージ間に制限されたqueue.Queueインスタンスを使用したthreadingでした。これは馴染みのあるブロッキングセマンティクスとスレッドセーフ性を提供しましたが、重度のGIL競合とコンテキストスイッチのオーバーヘッドに苦しみ、高スループット時の調整に15%のCPUを消費し、予測できない遅延スパイクを引き起こしました。
別の代替案として、asyncioコルーチンとasync/await構文への移行が考えられました。これはGILの競合を排除しましたが、我々の同期数値分析ライブラリをasync互換の形に完全に書き直す必要があり、何千行ものビジネスロジックに影響を与えるウイルス的なリファクタリングを生み出し、レガシーのC拡張との互換性の問題を引き起こしました。
最終的に、send()を使用して「需要クレジット」を上流に送信するジェネレータベースの協調マルチタスキングアプローチを選択しました。このソリューションは完全にGILオーバーヘッドを回避し、ジェネレータが同期コードで機能するため、ライブラリの書き換えは不要であり、下流の消費者がゼロの値を送信することで直ちに上流の生産を一時停止できる明示的な制御フローを提供しました。
その結果、キューアプローチに比べてメモリ使用量が40%減少し、レイテンシが5ミリ秒未満で安定し、コードベースは明示的なyieldポイントによって一時停止の境界が示され、読みやすさを維持しました。
新しく生成されたジェネレータに対して非None値でsend()を呼び出すとTypeErrorが発生するのはなぜであり、この制約がどのようにジェネレータプロトコルを強制するのか？
ジェネレータが最初に作成されると、そのフレームポインタf_lastiは-1となり、バイトコードが実行されていないことを示します。CPythonインタプリタは、send()が呼び出されたときにジェネレータが未開始であるかどうかをチェックします。送信された値がNoneでない場合、yield式がまだ到達していないためスタックスロットが提供されず、TypeErrorが発生します。この強制により、双方向通信が始まる前にジェネレータの初期化ロジックが完了することが保証され、値は明示的なyieldの一時停止ポイントでのみジェネレータに流れ込むという不変条件が維持されます。
generator.close()はどのようにしてジェネレータ内のクリーンアップコードが実行されることを保証し、GeneratorExit例外は通常の例外とどのように異なるのか？
close()メソッドは、throw(GeneratorExit)を呼び出すことにより、現在の一時停止ポイントでジェネレータにGeneratorExit例外を送信します。GeneratorExitはExceptionではなくBaseExceptionから継承され、一般的なexcept Exceptionハンドラによって捕捉されて適切に飲み込まれることを防ぎます。ジェネレータがGeneratorExitをキャッチして再発生させるか通常の終了をする場合、close()は静かに戻ります。しかし、ジェネレータがGeneratorExitに応じて値をyieldすると、CPythonはRuntimeErrorを発生させます。なぜなら、閉じるジェネレータは新しい値を生成してはならないからです。このメカニズムは、強制終了中でもジェネレータの本文内のfinallyブロックとコンテキストマネージャが実行されることを保証します。
どのメカニズムがyield fromが入れ子になったジェネレータ全体で送信された値を透明に処理することを可能にし、それはsend()を使用した手動の委任とどのように異なるか？
yield from構文は、単に反復だけでなく、サブジェネレータへの完全なジェネレータプロトコルを委任します。外側のジェネレータがyield from subgen()を実行すると、CPythonは呼び出し元のsend(value)をサブジェネレータへの直接送信に変換し、サブジェネレータがStopIterationを発生させるまで続きます（その値はyield from式の結果となります）。これは、for x in subgen(): yield xのようなループを使用した手動の委任とは異なり、外側のジェネレータに送信された値をキャッチして内側のジェネレータに転送することはできません。yield from構造は基本的にコールスタックをフラット化し、適切な例外伝播と終了セマンティクスを維持しながら、任意の深さのジェネレータネストを通じて双方向データフローを可能にします。