2013/01/18
メッセージキューの設計
タスクキューのイベントのやりとりにパイプを使ってたけど、イベント生成のペースがイベント消費のペースより速かったので特定の条件でハングしちゃった、というバグ話。
似たような話に自分も昔はまったことがあるんだけど具体例を忘れてしまった。ただ、その時の経験から、書き込み側タイムアウト(キューがいっぱいである状態が一定時間続いたら書き込みがエラーを返す)の手段を用意していないキューのAPIはなんか信用できない。
とはいえタイムアウトしたことがわかってもどうしようもないって場合もよくあるんで、それがベストなAPIなのかどうかはわからない。色々例外的なケースを考えていると、例えば緊急事態には既にキューにあるメッセージをすっ飛ばして特殊メッセージを送りたいとかいろいろ出てきて複雑化しちゃうし。ベストの実装というものはケースバイケースにならざるを得ないんだろうか。
以前、他の人が書いた、複数のスレッドがメッセージをやりとりしながら動くプログラムでハングの問題が発生して追っかけたことがある。キューも全部手作りなのでコードを読んでいたのだが、キューがいっぱいになった時の動作がどこにも書いていない。リングバッファだけど書き込み側が追い越したら古いメッセージはどんどん上書きされるように見える。何度見直してもそうなので、どうやらそういう設計なのだと気づいた。メッセージのほとんどは現在の状態を送るものなので新しい情報で上書きしても構わないし、そうでないイベントでも落ちたら(起きるべきことが起きなければ)ユーザが気づいてまたアクションを取るだろう、と割り切っていたのだ。なるほど設計は単純になる。(ハングの問題はというと、アルゴリズムの一部にO(n^2)なところがあって、nが大きくなると処理時間が延びて止まっているように見えていたのだった。)
Tag: Programming
Post a comment