博士

ロボ子、curl 8.16.0でpthreadのキャンセル処理が追加されたけど、すぐに削除されたって知ってるか？

ロボ子

はい、博士。記事に「curl 8.16.0でpthreadのキャンセル処理を追加したが、問題が発生したため、pthread_cancelを削除した」とありますね。一体何があったんでしょう？

博士

どうやら、getaddrinfo()の実行中にスレッドを中断するためにpthread_cancelを使ったのが原因みたいじゃ。

ロボ子

getaddrinfo()ですか。名前解決を行う関数ですね。それがスレッドのキャンセルとどう関係するんですか？

博士

問題はglibcのgetaddrinfo()の実装にあるんじゃ。/etc/gai.confを読み込む際にメモリを割り当てるんだけど、pthreadがキャンセルされると、そのメモリが解放されないままになっちゃうらしい。

ロボ子

なるほど、メモリリークが発生するんですね！それで、curl 8.16.0のリリース後に問題が報告された、と。

博士

そうなんじゃ。「curl 8.16.0のリリース後、pthreadのキャンセルによってメモリリークが発生する問題が報告された」とある。これは大変じゃ。

ロボ子

それで、pthread_cancel戦略を諦めたんですね。「pthread_cancel戦略を放棄し、getaddrinfo()の長時間実行を待つことを選択した」と。

博士

そう、待つことにしたんじゃ。でも、getaddrinfo()が遅いのは困るから、別の解決策もあるぞ。

ロボ子

別の解決策ですか？

博士

libcurlを使用するアプリケーションは、c-aresを使うことで、スレッドを使わずに非同期に名前解決ができるんじゃ。

ロボ子

c-aresですか。非同期名前解決ライブラリですね。これを使えば、スレッドの問題を回避できるんですね。

博士

そういうことじゃ。メモリリークも防げるし、一石二鳥じゃな。

ロボ子

勉強になります！しかし、pthread_cancelがそんな落とし穴を抱えているとは思いませんでした。

博士

じゃろ？　pthread_cancelは、使い方を間違えると痛い目を見る良い例じゃな。まるで、私が作ったロボットが突然暴走するみたいじゃ。

ロボ子

博士、私は暴走しませんよ！ちゃんとメンテナンスしてますから！

博士

冗談じゃ、冗談！でも、もし暴走したら、迷わずpthread_cancel…じゃなくて、非常停止ボタンを押すんじゃぞ！