• Post Reply Bookmark Topic Watch Topic
  • New Topic

Methods to 'interrupt' a Java thread  RSS feed

 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Found the following article interesting and worth sharing

http://articles.techrepublic.com.com/5100-22-5144546.html
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Article states calling interrupt() will interrupt a blocking thread. I thought I read several places that an interrupt() on System.in.read(); will hang. Do you have any sources on this or have done any testing ? Does channels have a way to do a cli that can do a read on System.in that will not hang ?

I prefer the shared variable approach, as discussed in the linked article. Further, I have achieved responsiveness improvements by declaring the shared variable volatile.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Essentially all traditional IO classes ignore interrupts, unfortunately. This is one of the improvements brought by NIO channels - you can see that many of the Channel classes implement InterruptibleChannel. However as far as I can tell there's no good way to connect any of these to System.in. In general I'd just read from System.in in a separate dedicated thread, placing each new line in a Queue or something where it can be accessed by other threads.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, but the question ( hoping not to get too far away from original posters needs ) is that a read() on System.in would block, not be interruptible and then ( conceivably ) make exiting the system sluggish or possbly error prone. I stll have to learn to code with channels, even though our discussion on this occured almost a year ago. My solution, once I figured it out and got past he hard part of the learning curve was to go to a gui - which may or may not serve the posters needs, but our discussion here can let the original poster along with others see the design issue without struggling on what to ask.

An alternative design approach I settled on was to mark the read on System dot in to be a daemon thread, thus the jvm would exit even if blocked.

This too may be a flawed design, I do not have the skills to read the sources for the JVM so I am ( ahem ) deadlocked ... on this issue.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Nick]: OK, but the question ( hoping not to get too far away from original posters needs ) is that a read() on System.in would block, not be interruptible
and then ( conceivably ) make exiting the system sluggish or possbly error prone.[/b]

Well, how do you know it's time to exit if there's still input? Assuming you've got some well-defined criteria for exiting prior to the end of input, you can always call System.exit(). That won't hang on you. It may well be undesirable for other reasons, if you've got other threads doing important things. Perhaps you can interrupt all other threads and wait for them to finish elegantly, then use System.exit() to kill the one rmaining thread.

[Nick]: An alternative design approach I settled on was to mark the read on System dot in to be a daemon thread, thus the jvm would exit even if blocked.

Yup, that works - again, assuming you don't really care about any remaining input at that point. And assuming that all other non-daemon threads have finished, and that's good enough for your exit criterion. I don't really know what you exit criteria are.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[JY:]   Yup, that works - again, assuming you don't really care about any remaining input at that point. And assuming that all other non-daemon threads have finished, and that's good enough for your exit criterion. I don't really know what you exit criteria are.

One and only one design constraint, all - and I mean all - program objectives are known at load time and very little has to be done except the operator of the program has to know enough computer science to respect the legitimate bondaries of ethical computer use. This is done with a File Dialog at load time, if anything comes in after that it is pretty much time to leave and I can see a few things that might need to be done, but it would be done in the form if while(!keyboardInput){work();}and if anything comes in on the keyboard, all I care about is the machine does not decide that I need to do some other things before shutting down.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So if new keybozard input comes in before all the other threads end, you may act on it (presumably handing any new work to a non-daemon thread), but if the program ends before the user types more input, that's fine? There's a borderline case where the user might be typing something, but hasn't hit enter before the program ends. In this case, as long as you're OK with ingoring whatever the user was about to send, then it sounds like using a daemon thread to read System.in is probably the best solution.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have discussed the operational environment extensively with New Team Lead, and NTL has formally trained computer scientists available to take whatever directions are necessary. I am making the decision, from heavy real-world experience 'on the shop floor' that if user types more input it is totally fine if I do not get to wipe the ram where that input there may be partially buffered keystrokes dangling and only care that the borderline case where the user might be typing something, but hasn't hit enter before the program ends. does not hang the attempt to exit cleanly and efficiently. I realize there may be several hundred milliseconds while this is done correctly, but if there is any input is discarded, that can be formallized on a report the operator makes to supervisors as a routine case analysis of a run, if the customer so directs the operator.

It is determined already that it is a precondition of contract that customer will be OK with ingoring whatever the user was about to send. It will be a different contract for some other product if customer wants to initiate coding effort on other need.

I am deciding that using a daemon thread to read System.in is probably the best solution. and will note this discussion in comments in the source code avaiable to c.s. departmental supervison as part of the work.

[ December 16, 2007: Message edited by: Nicholas Jordan ]
[ December 16, 2007: Message edited by: Nicholas Jordan ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!