久しぶりの今日のEBt

今日のメモ数とリンク数。

メモ数：7661
リンク数：64264

まぁ、メモ数は順調に増えていますが、それよりもリンク数の上昇が目につきますね。簡単に言えば、１メモあたりのリンク数が7→9に増えた。最近、新しくメモを作るより、既存メモとの間にリンクを張ることが増えてきたと何となく思っていたのですが、こうやって実際にカウントすると一目瞭然ですね。

今の調子だと、あと２年ぐらいでメモの数が10000の大台に突入しそうかな。いや、もうちょっとかかるか。1万メモに行く方が先か、10万リンクに行く方が先か。微妙なところだな。

なお、リンクによる管理方式は、かなり数に対する耐性がありそうですね。まだ破綻していません。まぁ、行方不明になったメモもいくつかあるので、全く破綻していないわけではありませんが…。見つからないのは、私のリンクの張り方がまずいだけだと思うけど。

さて、またぼちぼちとメモを書き溜めるか。

言ったそばから

Join で待っている間、メインのGUIが止まっちゃうじゃん…

というわけで、色々修正。推測した理由から、多分止まるであろうコードに変更（早い話が Join を呼ばない）。

まぁ、一応動くようになったけど、スレッドが止まらなかったときの考慮がないのがすごく気持ち悪い。

スレッドが止まらない保証がないんだよなぁ。うーん。デッドロック自体は再現はしなくなったんだけど（Join無くしたんだから起きようがないわな）。

やっぱり気持ち悪いなぁ。

EBt for Wiindows で、EBtWin.exe が終わらなくなる不具合が直った

まぁ、予期せぬデッドロックが起きていたというありがちな理由です。

しかしなぁ、予期せぬと言うところがねぇ。本当に予期せぬと言うか、理論的には発生しないデッドロックが発生しているのがどうも、ね。

.NET のアプリケーションは、基本的にシングルスレッドで動く訳なのですが、EBt for Windows(以下、EBtWin)はマルチスレッドで動いています。

んで、.NETでは、メインのGUIを制御するスレッド(スレッド1とする)以外からは、GUIの制御は基本的にできません。基本的にというところがミソで、アプリケーションが作成したスレッド(スレッド2とする)からGUIの制御をする場合、Invokeというメソッドを使う事で実現しています。

で、Invoke の実装の仕組みはブラックボックスなのだが、多分、スレッド1のイベントキューに、スレッド2のGUI制御メソッドを呼び出すというリクエストを保存する事で実現しているのではないかと勝手に想像している。

今回の不具合だが、結構複雑で、こんな順序でデッドロックが発生していたのではないかと想像している。

１）スレッド1がスレッド2に対してスレッド停止要求を出す。
２）スレッド１は、スレッド2の終了待ちをする(Thread.Join()を呼び出す)。
３）スレッド2で、Invokeメソッドが呼び出される。→スレッド1のイベントキューにInvokeのリクエストが保存される。
４）スレッド２が、イベントキューの終了待ちをする

てな感じで、スレッド1・スレッド2が見事両方とも Wait 状態になりデッドロックになった…と思っている。
スレッド１がwaitだったらInvokeリクエストを消費してくれればいいのだが、どうやら、そうでもないらしい。多分、スレッド1のイベント処理が終了しないといけないのだろうと勝手に判断。しかも、4)に突入したら、復帰しないような雰囲気。

まぁ、でも問題はこんなに単純ではないようで、想像した問題の回避策をコードに組み込んでも、やっぱりデッドロックする。何でだよ、何が悪いんだよ、教えてくれよ .NET よ。

GUIライブラリをスレッドセーフで構築するのは難しいのは十分にわかる。なので、Invoke みたいな仕組みを導入するのも仕方がないと思っている。けど、なんか、詰めが甘くないかなーという気がするのですよ、こういう動作を見ると。Microsoft の詰めの甘さが出ているなーという感じ。

で、最終的に打った回避策。

t.Join( xxxx ); // 理論的にデッドロックしていなかったら終了しているだけの時間
if ( t.IsAlive ){
t.Abort();
}

汚いと思わば汚いと思え。私も汚いと思っている。あー、ここまで汚いコード書くのはやっぱり嫌だなぁ。

先読みキューの重複チェックを入れた

昨日、先読み深さを深くしたら、キューのサイズが15万ぐらいになってしまったという事を書いた。このままほったらかしにしておく訳にもいかないので、早速修正。

ま、コードにしてほんの10行もない訳なのですが。

うん、15万から5000に減ったぞ。やっぱり、こういう基本的なところで手を抜いちゃいけないね。

ちなみに、まだ公開しません。もちょっと色々やりたい事もあるし、テストもちゃんとしたいしね。まぁ、テストと言っても、私がひたすら使い続けるだけなのですが。

新幹線移動中は暇なので

出張で東京に来ています。んで、新幹線で移動中に仕事の資料とか読むのも最近はいろいろ問題があるので（セキュリティがうるさいのよ）、VAIO type P で EBt for Windows のバグ修正とかをいくつかやりました。

とりあえず。

二つほどバグをつぶして、もちょっと時間があったので、先読みキャッシュの読み込み深さを可変にする対応を入れました。

が。

私のEBtデータを3階層先読みさせるとですね、先読みQueueのサイズが15万とかあり得ない数字になってしまいましたよ。予想していたけど。

…先読みキューの重複検査を入れないといけないね、確実に。15万のキューを消費するのは余裕で1時間とかかかっちゃいますよ。そうなると、すでに先読みする意味がない。

まぁ、手を抜くなと言うことですね。

あと、メモの一時復号化（暗号化メモの修正機能）の実装アイデアが浮かんだので、ついでにそれも実装しようかなーと思っています。あと、他にもいろいろと実装して、来月中ぐらいに次のバージョンのリリースかな。ファイル出力も作りたいんだよなぁ。最近、テキスト出力が必要なシチュエーションが増えてきてね、個人的に。

…とか言いながら、Windows7 で遊んでしまって EBt 修正する暇がなかったりして。

アイデアをまとめる

というか、アイデアだしの作業を延々やっています。仕事で。内容はかけませんが。

なので、実は EBt が大活躍だったりします。簡単なメモ書きはエディタで十分なのですが、アイデアをこねくり回す作業はエディタでは辛い。こういう場面は、EBt が得意とするところです。

まぁ、手前味噌ですけど。

で、ですね。最近、EBt の更新が止まっている理由が、「現在の EBt で自分が満足してしまっている」というのがあるのですよ。もちろん、機能を作りたいというのはありますが、さしあたり自分が困っていないとやる気にならなくてねぇ。

細かい機能修正とかはやっているのですが、公開するほど書き換えて無いしなぁ。

ま、余暇で作っているソフトだから、仕方ないですよね、こうなるのって。もちろん、趣味だから、ボチボチと続けますけど。

うーん、最初の頃の作らねば!という勢いが無くなったなぁ、最近。いかんなぁ。