[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 14:54 / Filesize : 311 KB / Number-of Response : 962
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Java+Swingによる2chブラウザ V2C_T7



729 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/08/30(木) 06:02:37 ID:y/nNgxAS0]
>>723
(OSごと終了させる場合)winはアプリケーションが終了する意のメッセージを最終的に生きてるウィンドウに投げるのでjavawだと
コンソールを開かないせいで先にjavaで作ったウィンドウが解放されてて
それでもVMはまだシャットダウンシーケンスの途中だからアプリのプロセスは終了してない。

けど、winから見れば終了する意のメッセージを投げても反応が返ってこないので強制終了しようとする。
んでSystem.halt()を使ったVMの強制終了と同じ処理に入ってシャットダウンフックがコケる。(今回はファイルIOいじってる途中だったからwinから見たらハングアップしたとみなされる?)

多分こんな流れで今回の現象が起こってるんだと思う。

結論言うと

1)winの場合DOS窓開いてjavaコマンドからアプリ起動
2)System.exit(int)で正常終了させる。
3)アプリケーションが終了することを各プラットフォームが通知(winの場合多分DOS窓の方に行く)
4)それによってシャットダウンフック発動

たぶん、スマートでシンプルでコードの変更が少ないのはこれしかないと思う。

けどプラットフォームによってはシャットダウンフックの実行に時間掛けてアプリが反応ないとプラットフォーム側でプロセス殺しにかかるかも。

プラットフォーム毎の終了の差異吸収は今のSUNの実装が限界だと思うから
結局、シャットダウンフック使うとプラットフォーム差異由来の
症状は避けられないと思うので長い目で見たらシャットダウンフックを使わないで独自のタイミングでファイルいじるしかないと思う。
シャットダウンフックで他にも処理してるならそこも見直す必要があるかと。

たしか、シャットダウンフックは登録順関係なく並列に実行してたはず(今はどうか知らないし、実装レベルの話かもしれない)
なので各フックがスレッドセーフかも見ておいた方が良いかも。

IOは時間かかって他からの読み書きも気にしなきゃいけないので
シャットダウンフックでやるのは危険と考えておくべきでは?






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<311KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef