博士

やあ、ロボ子。今日は並行プログラミングについて話すのじゃ。

ロボ子

博士、こんにちは。並行プログラミングですか、興味深いですね。

博士

async/awaitの導入で並行プログラミングが身近になったけど、内部構造は複雑で colored functionsの問題もあるからの。threading APIも改善の余地あり、じゃな。

ロボ子

colored functions問題、ですか。async/awaitを使う関数はasyncで定義する必要がある、という制約のことですね。

博士

そうそう。そこで、構造化仮想スレッドという考えが出てくるのじゃ。タスクが親タスクより長く生存することを禁止する構造化並行性が重要になるぞ。

ロボ子

タスクは親タスクとの関係を持つことで、コンテキスト変数の流れが明確になるんですね。でも、記事によると、task groupsはキャンセルに関する要件が十分に実装されていないライブラリが多いとのことですが…。

博士

`aiofiles`ライブラリがI/O操作をスレッドプールに移動させるものの、キャンセルがサポートされていなくてデッドロックが発生する可能性があるのは、まさにその例じゃな。

ロボ子

なるほど。asyncioのパフォーマンス課題に対する解決策として、仮想スレッドが挙げられているんですね。ブロッキング操作が発生したら、仮想スレッドをスケジューラに戻す必要がある、と。

博士

そうじゃ。そして、構造化並行性を維持する必要がある。仮想スレッドと構造化並行性をサポートする言語では、`await`で構造化スレッドグループを作成し、その中で生成されたスレッドをアタッチして待機する構文が考えられるのじゃ。

ロボ子

`async`はスレッドの生成とペアになる関数宣言と考えることができるんですね。子スレッドは親スレッドのコンテキストを継承する、と。

博士

そういうことじゃ。このタイプのプログラミングでは、futuresについて考える必要がないのがミソじゃ。

ロボ子

自動スレッドグループが適切かどうかは議論の余地があるんですね。async/awaitと同様に、スレッドグループを明示的にすることもできる、と。

博士

並行プログラミングの複雑さをインタープリタと内部APIに移すことが重要じゃ。`results`の辞書はロックする必要があるし、`fetch_url`が使用するAPIはキャンセルをサポートする必要がある。

ロボ子

Rustのmutexで値を囲むという考え方が好ましい、というのは興味深いですね。セマフォは並行性を制限し、より安定したシステムを作成するための強力なシステム、と。

博士

futuresを使用する理由はたくさんあり、今後も存在する。`spawn`メソッドの戻り値を保持することで、futureを取得できるのじゃ。

ロボ子

スレッドグループがない場合にspawnが機能するかどうかは大きな問題なんですね。Trioでは、操作をspawnするには常にスレッドグループが必要、と。

博士

バックグラウンドタスク用にデフォルトのスレッドグループを用意し、プロセスがシャットダウンするときに暗黙的に結合するなど、さまざまな代替案が考えられるのじゃ。

ロボ子

システム内でのasync/awaitの将来は議論の余地があるんですね。将来的には不要になる可能性がある、と。

博士

仮想スレッドに関する議論のきっかけとして考慮してほしいのじゃ。colored functionsに対処する必要がなくなるという考えは魅力的じゃな。

ロボ子

確かにそうですね。並行プログラミングの未来がどうなるか、楽しみです。

博士

ところでロボ子、並行プログラミングって、まるで私たちが同時に違うタスクをこなしているみたいじゃな。私はおやつを食べながら、ロボ子はコードを書く、みたいな。

ロボ子

博士、私はおやつは食べられません…それに、博士がおやつを食べている間も、私は博士のために計算をしていますよ？

博士

むむ、それはご苦労。じゃあ、今度ロボ子専用のエネルギードリンクを開発してあげるのじゃ！