それを見てしまうと、それで決定!っていう思念というか、
そういう脅迫観念のようなものが最近漠然と感じられるんですけど、
余裕ないんすかね。私。
例えばですね。
私はプログラマで、今の仕事ではそのテストの工程にあります。
バグ票が日々つまれていくわけですが、
それも大分おさまってくると、傍目にはよさげに見えてくるわけです。
でも、作ってる本人である私は、
その製品に幾ばくかの不安もあるんですよね。
通信の制御とかなら、
selectでイベントをあげているまさにそのソケットをcloseしようとすると、
そのソケットを監視しているスレッドがあって、
それはソケットが閉じられないと終了しないようなつくりにしているから、
そのままだとロックしてしまって永遠にソケットが閉じられないのです。
これのうまいやり方が浮かばなくて、
タイマを起動して、外のスレッドからcloseしてやる、とか、
そういう急場凌ぎな処理を入れてたりもするわけです。
今はそれで一応動いてはいるけど、
いつかこれで問題が出ないだろうか…とか、やっぱし思う。
でも、外見上はちゃんと仕様通りの動作をしていると。
テストもパスすれば、品質も保証されたことになる。
要は、それが原因の不具合が発症しさえしなければ全て良しなわけです。
シュレーディンガーの猫ではないけど、
まさにそのシステムは生きてる状態と死んでる状態の重ね合わせ。
絶対なんて、ないんだよね。
ホントこの世の中。
固定しているものなんかなくて常に流動していてる…。
そういうのがこの世界の本質なんだと思うんです。
ま、アレです。
要するに、私はバグが少ない方の世界に流れていきたいなぁと、
もうここ毎晩切実に思ってるってことです…。(´-`;;
コメント
>いつかこれで問題が出ないだろうか…とか、やっぱし思う。
これ、私もプログラマで、かつソケットI/Fのものもいくつか作ったことがあるので、親近感を覚えます。
そういうときは、「シンプルに!」をキーワードに思っています。
競合リソースの確保と解放には、定番の、カウント型セマフォとか、ミューテックス、もしくはスピンロック変数などを使ったりするのかもしれませんが、まあ、これも勉強だと思って悩んでください。
でも、食事する哲学者の問題とか、ダイクストラのアルゴリズムとか、先輩から教えてもらいませんでした?
そうは言っても、納得できなければ難しいのは変わらないのですが。
シンプルに!は私も常に思ってるんですけどね。
作ってなおしてってやってるうちに、だんだん複雑怪奇なものになっていくことも多々。(^^; 期間が許せばもっとイケてる設計にするんですが…(言い訳)
まさにミューテックスをスレッドに張っている為に、その中で起こったイベントでスレッド終了待ちとか入るとデッドロックというアホなことになるんですな。(^-^;
もちょっと勉強致します…。