BluntIRC

かなり間があいたけど久しぶりにsf.jpにリリースを置いてみた。

java 1.4.2のnioのselectはop_connect とネットワークunpluggedで期待しない動作をする。sunのバグデータベースでop_connectやop_acceptで探すと出てくる。どちらも動作が分かってしまえばコード側で対応可能だった。connectが成功しても失敗してもop_connectを外すとか、ある程度長いタイムアウトを指定したのにすぐに帰ってきてしかも何も操作可能なものがないときはチャネルを保存してセレクタを開きなおし再度登録するとか。

対応した結果、ノートPCでCPUを浪費する問題はなくなった。op_writeについて誤解して対応した処理も不要になった。ソケットまわりは快適といっていい状態になったようだ。現状はmainのスレッドがselectしてからSwingUtilities.invokeAndWait()の中でソケットをノンブロックに処理し、あとはSwingのイベントディスパッチスレッドとjavax.swing.Timerが一つ動いているだけ。無駄にスレッドを使わないのはよいことだ。ネイティブスタックを取られてメモリが膨れることもないし、GUIまわりの排他を考える必要もなくなるし。

windowsのjavaにまだまだリソースリークが残っているようだ。sunのバグデータベースでleakで検索すると出るわ出るわ。タスクマネージャでハンドルを表示させてBluntIRCを観察するとハンドルが徐々に増えていき、10000弱で動作がおかしくなる。この時仮想メモリを153MBほど消費している。チャットのようなコネクションを延々と張りっぱなし＆24時間起動が前提のアプリケーションだとリークは勘弁してほしいところだ。sunが対応するのを待つしかないんだろうか、これって。でも戦略的にやってくれなさそうなきもする。

java.util.logging.Logger の出力をウィンドウ内に出すようにしてメニューから詳細レベルを変更できるようにした。DynamicJavaのデバッグがやや快適になったかな。DynamicJavaは全然更新されてないな。パースエラーとか実行時エラーとかの読み方がまちまちだとかよくわからんが動かないところがあるとか、そのあたりに不満がある。

ノートをシャットダウンした時にアプリケーションの終了処理が間に合わず、設定ファイルが中途半端な状態で切れることがある。closeする前に落ちている感じだろうか。起動時に設定ファイルのバックアップを取るような仕組みをまず思いつくが、根本的な解決ではないし。WM_QUERYENDSESSION を扱えたらいいんだが、せっかくここまでほとんど機種依存なしで（もしくはDynamicJavaで動的クラスロードにして）組んだんだからjniなしでなんとかしたいところ。なお addShutdownHook はVMの終了に関する物でOSのシャットダウンとは関係ない。