• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

interrupt() for ending thread execution and asynchronous i/o

 
Saurabh M Sirdeshmukh
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys, I came across many apis suggesting that interrupt() is d best way to terminating a thread execution especially those performing blocking operations. i pretty much agree with it n also helpful for doing any clean-up act before ending thread execution. but what i e wanna ensure from all you guys is: how actually that thread wil end? is it by returning from the run()? becoz stop() n destroy() are to b ultimately avoided...


2nd: i believe I/O in java is synchronous or blocking...if there is just a single thread n it does read() in System.in then it wil definitely block.if i wanna implement it asynchronousely then I can do this reading in another thread while doing some work in current thread?
Is this approach right?
lemme know


 
Henry Wong
author
Marshal
Pie
Posts: 21427
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys, I came across many apis suggesting that interrupt() is d best way to terminating a thread execution especially those performing blocking operations. i pretty much agree with it n also helpful for doing any clean-up act before ending thread execution. but what i e wanna ensure from all you guys is: how actually that thread wil end? is it by returning from the run()? becoz stop() n destroy() are to b ultimately avoided...



When you interrupt a thread -- it doesn't just end. It gets the interrupt signal, and your thread must deal with it. It is your thread's responsibility to clean up after itself.... Meaning....

1. If the thread gets interrupted while running, it will get marked as interrupted. It is the threads responsibility to check the flag, once in a while (if it is compute intensive), and abort the calculation and clean up after itself.

2. If the thread gets interrupted while in a wait(), sleep(), join(), etc., it will get an interrupted exception. Again, it is the threads responsibility to abort whatever it is doing and clean up after itself.

3. If the thread gets interrupted while doing IO, it is platform independant. On some systems, you will get an interrupted IO exception. On other systems, it won't work by itself. You also need to close the network or file that the thread is using. In this case, the thread will get an IO exception and can then check the interrupted flag.... And again, it is the threads responsibility to abort whatever it is doing and clean up after itself.




2nd: i believe I/O in java is synchronous or blocking...if there is just a single thread n it does read() in System.in then it wil definitely block.if i wanna implement it asynchronousely then I can do this reading in another thread while doing some work in current thread?
Is this approach right?
lemme know


Yes, threading is one solution to have your program not wait for a blocking IO operation. Another option is to using non-blocking IO via the NIO package.

Henry
 
Arka Guhathakurta
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry you are an extremely knowledgable as well as talented individual....I wish I could be 1% of you.
 
Saurabh M Sirdeshmukh
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Henry, thanks a lot.
and can you please tell me what does the terms: "synchronous" n "asynchronous" in context of exceptions.
and how these terms are expected to be interpreted in background of java threads?
n by the way are you the same Henry Wong, author of Java threads book? privilig to here from you
thanks.
 
Alan Mehio
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Guys, I came across many apis suggesting that interrupt() is d best way to terminating a thread execution especially those performing blocking operations. i pretty much agree with it n also helpful for doing any clean-up act before ending thread execution. but what i e wanna ensure from all you guys is: how actually that thread wil end? is it by returning from the run()? becoz stop() n destroy() are to b ultimately avoided...

Just to add more details by giving example to show who we deal with interruption







2nd: i believe I/O in java is synchronous or blocking...if there is just a single thread n it does read() in System.in then it wil definitely block.if i wanna implement it asynchronousely then I can do this reading in another thread while doing some work in current thread?
Is this approach right?
lemme know


The synchronous means here the thread can not move forward ( serial behaviour) unless the method which is a blocking method (reading or writing to input or output Stream are not responsive to interruption in java.io package) so you the only thing you can do if it is a socket or a stream is to close it ( you will have a reference to )

In the asyncrhonouse situation where you do not want to see the effect of block so If a thread is blocked in a Selector.select(java.nio.channels)method, the
Selector.wakeup method causes it to return prematurely by throwing a ClosedSelectorException
so this will make the thread to work in an asynchronous behaviour




 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic