[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends] Re: Thread#interrupt()
下村です。
Shinさんありがとうございます。
shin> もしかしたら、try{sleep(??);}catch(InterruptedException e){}
shin> を実行しているThreadオブジェクトのinterrupt();を呼んでいないのでは?
shin> 大分前なんですがinterrupt();で正常にInterruptedExceptionが
shin> 発生したのを確認した記憶があります.
すみません、おおボケしてました。interrupt() を呼んだあとで stop() も
呼んでいたため、catch ブロックの中が実行される前にスレッドが死んでしまう
ことがあったようです。ご指摘の通り、interrupt() は正常に働いていました。
実行中に interrupt() が呼ばれた場合は、sleep() を呼んだ直後に
InterruptedException が発生するようです。これは確かに有用ですね。
shin> 想像ですが(すみません仕様書よく呼んでません)、
shin> 「中断」ではなくそのThreadオブジェクトに対して
shin> (過去に)interrupt();が呼び出されたかどうかを調べるためだと思います.
なるほど。そのようですね。
shin> によって外部からThreadを安全に終了させる(stop()を使わずに)手段ができたと
shin> 思っているのですが、いまだにInputStream#read()やServerSocket#accept()
shin> を外部からやめさせる方法が分かっていません.
shin> (これは個人的な話ですが)
ServerSocket#accept() は、他のスレッドで ServerSocket#close() を呼び、
ブロッキングしているスレッドで SocketException を catch すればよい
と思います。(実験済み)
InputStream#read() が interrupt() を呼ばれても InterruptedIOException を
投げて中断しないのはバグじゃないかなという気もします。
JDK のリファレンスには See Also : interrupt とあるのに。
フラグを立ててから InputStream#close() を呼んで IOException を
catch するという手は使えないでしょうか。実験はしていませんが。
では。
=== == = TACT/下村哲人 神奈川県横浜市 = == ===
=== == = E-mail: tact@xxxxxxxxxx = == ===