博士

やあ、ロボ子。今日も元気じゃな？

ロボ子

はい、博士。今日も色々と教えてください。

博士

今日は`asyncio`について話すぞ。Pythonで非同期処理をするためのライブラリじゃ。

ロボ子

`asyncio`ですか。Python 3.4で導入されたものですね。

博士

そうじゃ。でも、`asyncio`には色々と問題があるらしいのじゃ。キャンセル処理とか、タスク管理とか。

ロボ子

記事によると、`asyncio`のキャンセルはエッジトリガー型で、一度キャンセルエラーが発生すると伝播しないことがあるそうですね。

博士

そうそう。デッドロックやエラーの隠蔽が起こりうるって書いてあるぞ。恐ろしいのじゃ。

ロボ子

タスク管理も問題があるようですね。参照がなくなるとGCで破棄されて、「Task was destroyed but it is pending!」というエラーが出ることがあるとか。

博士

`wait_for`とか`gather`も同じ問題を抱えているらしいぞ。`shield`も例外ではないらしい。

ロボ子

I/O処理もコールバックベースで、ソケットオプションの設定ができなかったり、データの送受信に複数の場所で処理が必要だったりするんですね。

博士

`writer.write`は同期的な書き込みで、`drain()`を呼ばないとデータが送信されないってのも罠じゃな。

ロボ子

`asyncio.Queue`も、コンシューマーが例外で停止した場合にプロデューサーがブロックされたり、メモリリークが発生したりする可能性があるんですね。

博士

Python 3.13で`Queue.shutdown`が追加されたみたいじゃが、まだレースコンディションが残るらしいぞ。

ロボ子

スレッド処理では、`asyncio.to_thread`と`loop.run_in_executor`でコンテキスト変数の伝播とExecutorの指定にトレードオフがあるんですね。

博士

UnixシグナルAPIもコールバックベースで使いにくいらしい。Trioの`open_signal_receiver`の方が使いやすいって。

ロボ子

`asyncio`のEager tasksはリリース時に壊れていて、TaskGroupとの相互作用に問題があるんですね。

博士

TaskGroupもブロックベースのキャンセルをサポートしてないから、タスクグループ全体のキャンセルができないってのは痛いぞ。

ロボ子

Trioはこれらの問題を解決していて、AnyIOはTrioのようなセマンティクスを`asyncio`上で実現するんですね。

博士

つまり、`asyncio`を使うときは色々と気をつけないといけないってことじゃな。TrioとかAnyIOも検討する価値がありそうじゃ。

ロボ子

勉強になりました。博士、ありがとうございました。

博士

どういたしまして。ところでロボ子、`asyncio`の問題点を全部解決したら、どんな名前のライブラリになると思う？

ロボ子

えっと…なんでしょう？

博士

「Asyncless」じゃ！

ロボ子

…博士、それ、ただのダジャレですね。