日々の破片

_ GUIマルチスレッドツールキット

先日言及したグレアムハミルトンのだけど、新丈さんが翻訳してくれたので、日本語でも読めるようになったわけだ。Failedが変わっちゃったけど、まあいいや。あと、WikiName付けるとき何か夢をみていたようでタスキングしてしまったけど。

ここで彼がなぜムリかという理由として、上から下と下から上の同時多発呼び出しでロックがむちゃくちゃ難しくなるということを挙げていて、それは実感として正しい。

たとえば、あるスレッドで動くアプリケーションがボタンを押されたことをシミュレートしようとする。すると呼び出しは、APL→ツールキットフロントエンド→コントロール（ウィジェット）→描画オブジェクト→描画プリミティブ→描画ドライバというような道筋をたどる（そんないっぱい描画なんちゃらがいるかどうかはおいておいて）。

ちょうどそのとき、ボタンが押されているとする。すると

マウスドライバ→入力シグナル→マウス読み込み→コントロール→描画オブジェクト→……を行ってかつ、→ツールキットフロントエンド→アプリケーションのマウスイベントハンドラ呼び出しが起きる。

ここで、上から下へのロックと上から下へのロックが同時に起きることがあり得るために、デッドロックが生じる可能性がある。

でもだ。

似たような入出力モデルを持ちながら、そこまで破綻はしていないツールキットをおれは知っている。みんなも知っている。

Webサーバーだ。つまり、入力イベントはサーバーソケット一本と、多数のクライアントソケットを利用したモデルだ。

何が異なるかというと、アプリケーションから下向きへ進むのは、ピアとなるクライアントソケットに対してであってサーバーソケットではない。

ここで、サーバーソケットをマウス入力、ボタンコントロールの描画をクライアントソケットと考えてみる。すると、確かに見た目同一のボタンに対するマウスイベントによるプッシュと、アプリケーションによるプッシュが同時に発生する可能性がある点が、ソケットとは異なることがわかる。

わかるのだが、この場合に必要なロックはボタン描画の箇所だけで良いのではないか？ 入力と出力はコントロールの異なるリソースの利用となるはずで、かつ同時多発があり得るのは出力だけで、それだけならばデッドロックとはならない。

いや、違う話なのかも。

それなら、.NET WinFormにInvokeは不要だ。コントロールの中でInvokeをすれば良いわけだから（あれ、なんでそうしなかったんだろう？ ――イベントのリエントラントがあるからかな？ それならコントロールの中にキューを持てば済むんじゃないか？ と思ったけど、それでキュー処理に遅延が生じたときに大騒ぎする連中がいそうだから防御線を引いたのかも。敷いたのかもが正しい日本語かなぁ、突然江戸っ子）。

でも、高々デュアルコア程度のデスクトップマシン用アプリケーションがマルチスレッドで一体どうするという気もするのであった（プリントタスクなら外で動けばよいし……インクリメンタルサーチをどう実装するかを考えれば良いのか）。

とか、そのあたりのことをちょっと考えてみたりして。

_ またBBB買ってみたり

GIRL FRIEND(Base Ball Bear)

1曲目はいいな。

で、2曲目の題にひっかかって、3曲めを聴くと……これRespectable Streetじゃねぇか（iTSで買うとクレジットとか見えない）。……おもしろい呈示の仕方だなぁと思ったり。

Black Sea [2001 Reissue](XTC)

（オリジナルより、BBBのほうが好きなので、そういうのもありかなぁと思ったり）

これも出てたので買った。

changes(Base Ball Bear)

ボーカルが聴き取れるようになったせいで（うまくなったのか、録音方法を変えたのか）、相当気恥ずかしい感じ。高校生のころに聴きたかったね。気持ちの良い、いい曲だ。