Repo
kjana00@gmail.com
2011-05-11 01:30:18
今朝は雨。朝ごはんはパンとサラダとソーセージ。蒸し蒸しして気分悪い。昨日じゃなくて良かったわ、ほんと。連休明け初日がこれだったらたまらない。二日目でも十分たまらないけど。
昨日の晩ので十分直ったよね、というのを確認してたら手動でコマンドを発行した場合に飛ぶパケットの内容がおかしいのに気付く。気付いたからには直さなきゃだめだろうということでまた調べものへ。外部的な挙動だけ見ててもさっぱりだったんで ICE を使ってみたらさっくり。ループで見つけた ID じゃなくてループ抜けてきた時の変数値をインデックスにして見てたらそりゃ変だよねっていうのと、そもそも見つけた時に break してないぞっていうのと。外から見てると特定のパラメータではちゃんと動いてるのに別のパラメータだとパケットが飛びすらしない場合がある、っていうのしか見えないからちょっと辛い。
そっちが片付いてから、何だか取りこぼしがあるんだけどっていう話の方へ。これ、昨日帰る時に 10ms に一回動くタスクの中にあるけど実は中身 100ms に一回しか呼ばれないんじゃなかったっけというのに思い至ってた。実際に今日になってコードを見直してみてもその通り。同期信号は 100ms に一回発行されて、その返事が全部集まってたら情報取得関数がまとめた情報を更新する。集まってなかったら更新しない。返事が全部集まるタイミングが常に情報取得関数の呼び出しの前なら問題無いけど、そうでない場合はたまに返事が集まりきらないタイミングを踏んで前に更新された値を返す。……まあ、知ってたことではある。
10ms に一回動くタスクの中にあるから 10ms に一回呼ばれてて、そうすると同期信号が発行される前にどこかで情報が更新されて最悪でも一つ前の同期信号に対する返事を集めた情報が見えるはず。100ms 単位では返事が全部揃うっていうのはわかってるからデバッグ用モニタへの情報はほぼ毎回更新されると見ていいだろう……という予断を本当のことにしてやると取りこぼしっぽい現象は格段に減った、っていうかちょっと見てた分には出なくなったんでそれで良しとしておく。メッセージ受信関数で全部メッセージが集まったら情報を更新っていう形の方がいいんだろうけど、そのためのバッファが他のモジュールにあるから何か気持ち悪いとかでこの形なんだよね……まあ後を任せる人達に何とかしてもらうところか。故障検出周りとか、通信周りとか、いらなくなるモジュール周りとか、とりあえずでごまかしたところ色々と一緒に直してもらいましょう。
後は来週からの仕事についてあれこれ打ち合わせだったり資料を読み始めたりな感じでおしまい。うーん、これ、面倒臭い……で、適当に切り上げて、しばらくぶりに早めに帰る。あまりにも蒸し暑くて気持ち悪いもんだから晩ごはんは冷奴とかつおのたたきととろろ昆布のつゆと枝豆。さっぱり。
後は WWW 見たりゲームしたり、何だか妙に眠くなって一寝入りしたり。勝負とばかりに飛び込んだ 24 階のランダムクエストは弱い相手を引けて簡単に勝利。収入は悪いけど。おまけに陽気なレプラコーン大量発生を防げなかったんで半分ぐらい回ったところで帰ったんだけど。とまれ、25 階レベルのクエストが視野に入ってきたか。