今月の頭から、ひたすら
解析を続けさせられていた不具合の原因は、判明。
後は対策。
原因だけわかれば、後は、料理のし様もある。
POSIXタイマの実装が、微妙。
ユーザーのtimeout-handlerを
登録したtaskのcontextでやらせるってのは、どうなのだろう?
signal-handlerは、
taskの持つsignal-event queueにeventを積むだけ。
そのtaskにcontext-switchしないと、timeout-handlerは動かない。
OSの最小分解能が10ms、しかも、
timeoutが動くのは、ユーザーのtask-context.
民生品のOSなら、それでも十分な精度なのか?
とりあえず、interval-timerは使う気になれない。
signalが複数積まれていた場合に、
signal-event queueが空になるまで処理する仕様は、怖すぎる。
timeout-handlerの処理が終わる前に次のsignalが入り続けたら、
いつか、stackが溢れる。
ずっと、
うちだけじゃ、解析は不可能ですよ
OS屋も手伝ってくださいよと言い続けて、2週間。
ありがとう、OS屋の人。
おかげで、今週末は休みが貰えそうだ。
解析を続けさせられていた不具合の原因は、判明。
後は対策。
原因だけわかれば、後は、料理のし様もある。
POSIXタイマの実装が、微妙。
ユーザーのtimeout-handlerを
登録したtaskのcontextでやらせるってのは、どうなのだろう?
signal-handlerは、
taskの持つsignal-event queueにeventを積むだけ。
そのtaskにcontext-switchしないと、timeout-handlerは動かない。
OSの最小分解能が10ms、しかも、
timeoutが動くのは、ユーザーのtask-context.
民生品のOSなら、それでも十分な精度なのか?
とりあえず、interval-timerは使う気になれない。
signalが複数積まれていた場合に、
signal-event queueが空になるまで処理する仕様は、怖すぎる。
timeout-handlerの処理が終わる前に次のsignalが入り続けたら、
いつか、stackが溢れる。
ずっと、
うちだけじゃ、解析は不可能ですよ
OS屋も手伝ってくださいよと言い続けて、2週間。
ありがとう、OS屋の人。
おかげで、今週末は休みが貰えそうだ。
コメント