[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      = == ===