• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using interrupt() to stop a thread

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I read Maha Anna's nice explanation about how interrupt() acts on waiting threads & non-waiting threads.
In the latter case Maha explained that interrupt() can be used for stopping a thread. But I could not understand one thing.
Maha says that stopper-thread must set a boolean hastoDie variable to true. And then the stopper-thread must send an interrupt() to the target-thread, which will set the interrupted-flag of target-thread. But, she also says that the target-thread must cooperate, by periodically checking the boolean hastoDie variable. If the target-thread finds that hastoDie is set to true, it must return from its run() method.
Now, if the target-thread must, on its own keep checking the hastoDie variable, why should the stopper thread need to send an interrupt() at all? What is the advantage of interrupt(), when the target-thread will, in any case, find out the setting of hastoDie, and return from its run() ?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm moving this to Threads...
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the target thread is currently waiting or sleeping, then it will continue waiting or sleeping unless you call interrupt(). After that it can check the value of hasToDie.
 
Rahul R
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Jim.
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim Yingst,
If a thread is in not-runnable state because IO block, can i use interrupt as above to stop the thread?

 
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Li
Sorry for poking my nose in your query to Jim. But I happen to have the answer here. The answer is NO. This question has been specifically dealt with in the API documentation, and also discussed in many other posts. The only way to make the thread come out of the blocked state (without using deprecated methods) is to do stream.close() to the input/output stream to unblock the thread. The thread will come out of the block because an IOException will be thrown, as soon as the stream is closed. Catch that IOException and make the thread return from its run() method to kill it.
 
Li Shangqiang
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
I've got it. thanks.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rahul Rathore:
Sorry for poking my nose in your query to Jim. But I happen to have the answer here. The answer is NO. This question has been specifically dealt with in the API documentation, and also discussed in many other posts.


Where exactly in the API documentation? In fact, it seems to leave the possibility explicitly open: if you look in the Javadoc for java.io.InterruptedIOException, it says "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was terminated. [...] See Also: [...] Thread.interrupt()".
While I will be the first to admit that my attempts to get (network) I/O blocked threads to throw an InterruptedIOException have failed miserably so far, the API seems to support it in concept.
- Peter
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter
Thanks for raising the question. It forced me to think clearly.
I will work on this further. I hope we continue the discussion.

[This message has been edited by Rahul Rathore (edited April 07, 2001).]
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter
This is the API doc:-


What if a thread doesn't respond to Thread.interrupt?
In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly.



I have done testing on network IO.
Closing the stream does work and so does closing the socket. Either closing the stream or closing the socket will cause an exception to be thrown, unblocking the thread.
The client and server code I used for testing is this:


As regards InterruptedIOException the documentation says that


"An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was terminated"


So this has nothing to do with a thread being "interrupted". It talks of the situation where the thread was "terminated" A thread would terminate, for example, when the deprecated stop() is used.

[This message has been edited by Rahul Rathore (edited April 07, 2001).]
[This message has been edited by Rahul Rathore (edited April 07, 2001).]
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I repeat the assertion that an interrupt will NEVER unblock a blocked thread eg. a thread blocked while doing read() from a socket stream.
I will be very glad to see contradiction/clarification/debate.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rahul Rathore:
I repeat the assertion that an interrupt will NEVER unblock a blocked thread eg. a thread blocked while doing read() from a socket stream.


Rahul,
Some time ago I did a test quite similar to yours, and with the same result. Please note that I was honest enough to mention that my attempts to let blocked network I/O throw an InterruptedIOException had failed
We agree that an interrupt() will not unblock network I/O in the current implementation. On the other hand, the InterruptedIOException documentation quoted above explicitly refers to Thread.interrupt(), flatly contradicting your statement that this has nothing to do with a thread being "interrupted".
The truth apparently is that you cannot make assumptions either way. Blocked I/O may throw an InterruptedIOException when the thread executing them is interrupted, but it is clearly not guaranteed to.
- Peter
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter
My statement was deliberately meant to provoke a rebuttal. I was hoping that you (or some other guru) would show me the light. But we remain in the dark. Both of us are simply trying to read between the lines and make deductions from a sloppy API documentation.
But I do admit that I have made statements which appear very categorical and definitive. Such assertiveness is not warranted either by my knowledge or by the API documentation (or the lack of it). On the other hand your conclusions are also not warranted from the API documentation.
I would be very-very grateful to you, if you could show me a single example whether in network or in local IO where interrupt() causes an InterruptedIOException to be thrown.
Hoping I have sufficiently incited you to retaliate with the truth.
With Respect
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic