This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
hi, i wanna know what is the way of killing a thread from a seperate thread besides using the depricated api thread.stop(); ....... i have implemented a threadpool which is supposed to kill a thread after timeout.
I don't think there is any direct way of doing that with stop() being depricated. I guess it could be possible to rig up an indirect way of making the thread you want to kill, kill itself on timeout if the processing happens in a loop (which is usually the case). You cannot control the exact time that will happen, but it is possible to introduce your own timeout check at the start of every loop in the run method of the thread you want to kill, and return without further processing if the timeout is exceeded. You can alternatively do it by seting up a boolean flag (true => the thread continues to run)and set the flag to false when you want it to stop (return from the run method). There is no "one way" of doing this - you have to figure out the best way to do it in the context of your application. However this is not really "kill"-ing a thread , but making it run to a graceful completion. Hope this helps, - ortimus
I think what I have to say is a restatement of what Ortimus has just said. The interrupt() method is a request to cancel a thread. The interruption status is set to true. The interrupted thread must check the status with isInterrupted() or interrupted(). I think the reason one thread is not allowed to stop another thread is related to problems caused if the thread is holding locks. [ December 14, 2003: Message edited by: Marlene Miller ]
Hi Marlene, Thread.interrupt(), isInterrupted(), interrupted(), InterruptedException, ... all related stuff which were discussed on the SCJD forum in August without getting a definitive answer to the issues envolved (IMO). It has been discussed here, unfortunately within a quite huge thread on another subject. InterruptedException is discussed from the post dated August 26, 2003 09:11 AM, and then mainly on the second page. You'll see there that no camp could convince the other one. Would be great if you put your 2 cents in it ! Best, Phil. [ December 15, 2003: Message edited by: Philippe Maquet ]
[MM]: The interrupted thread must check the status with isInterrupted() or interrupted(). Or by calling a method like sleep() or wait() which can throw an InterruptedException. Even if the interruption occurred prior to the sleep() or wait(), if the status hasn't been cleared by calling interrupted() then the sleep() or wait() will immediately throw an InterruptedException and clear the status. So if you're caling one of these methods, you don't really need to call interrupted() or isInterrupted() - but you do need to catch or throw the InterruptedException. How and where you place the catch block (if you use one) will determine whether the method keeps executing or not, and what exactly it does when interrupted. [PM]: You'll see there that no camp could convince the other one Camps? Wasn't it just two people by then (when you got around to isInterrupted())? I can't even tell what the question was at that point. There are too many other things under discussion at the same time. If there's still some question about how interruptions work, could you please state it clearly in a separate thread? Thanks...
"I'm not back." - Bill Harding, Twister
Joined: Mar 05, 2003
Thank you Jim for extending my remark. Philippe, thread questions are fun. I'll look at the other post and see if I can offer any ideas.
Joined: Jun 02, 2003
How and where you place the catch block (if you use one) will determine whether the method keeps executing or not, and what exactly it does when interrupted.
I can't even tell what the question was at that point.
My position (and I couldn't get it validated in that long thread) is that interrupt() just sends a signal to the running thread that it should interrupt itself. That "signal" is a simple boolean flag. When the target thread is running, it can check that flag. The problem comes with a target thread being in a wait state : how could it check its interrupted flag as, by definition, it's doing nothing ? The solution is given by the InterruptedException which is thrown to a thread which is interrupted while in a wait stait. The whole discussion (within another main subject) turned around InterruptedException and the way the coder should handle it. Most of people in this discussion suggested to throw some RuntimeException, arguing that such an interruption should never happen. My position was quite different in the context of a general-purpose class (a MultiReadSingleWriteSynchronizer class) from where I couldn't make any assumption on the context in which my class would be used. So I chose to call Thread.currentThread().interrupt() from the catch block, to offer my class what I called "Thread interruption transparency". As the InterruptedException has as side effect to swallow the interrupted flag (as interrupted() does BTW), calling interrupt() from the catch block is the only way I found out to let my MultiReadSingleWriteSynchronizer class usable by a class which would count on isInterrupted(). Now as nobody agreed with my position there (despite my numerous efforts ), I thought that Marlene could help me in convincing myself that what I wrote there makes some sense. Now I think that such an issue is more a language question than a development one, in such a way that this forum (SCJP) may be more appropriate than the SCJD one for this sort of theoritical stuff. Anyway I guess that, as usual, Marlene will give us some useful opinion of her ! Thank you in advance ! Best, Phil. [ December 15, 2003: Message edited by: Philippe Maquet ]
You may say that we're "using" a catch block which is provided for us by the JVM behind the scenes, but that's a stretch. My point is that it's often possible - and often even preferable in some contexts - to declare a checked exception in your throws clause, instead of catching it. The problem comes with a target thread being in a wait state : how could it check its interrupted flag as, by definition, it's doing nothing ? By definition, it's doing nothing until it's notified, or it's interrupted, or it times out (if you use wait() with timeout). The solution is given by the InterruptedException which is thrown to a thread which is interrupted while in a wait stait. Right... As for your old discussion topic, I don't think it's appropriate to respond to such a convoluted scenario here in SCJP where they really don't need to worry about all that. Gotta go now; later I may try to wade though that long discussion again to figure out what you're talking about. Cheers...
If the thread that must be stopped is reading from network or from file, it can't be interrupted. The best way, in this case is to use a Socket and setting a timeout on reading operation.
Joined: Jan 30, 2000
I/O is not on the SCJP exam anymore, so people just interestd in the exam should skip this (or don't worry about it too much). For I/O the interrupt() method doesn't work very well, since most I/O methods do not allow InterruptedException, and they don't check the interrupted() status. Of course if you're doing reads in a loop, you can check interrupted() yourself every time you repeat the loop. But if an I/O method is blocking while waiting for data, this won't work because the interrupted() check won't be executed until after the method unblocks. You do have some other options though with java.nio classes. You can close() a FileChannel from another thread, and that will cause previously blocked methods to throw a ClosedChannelException. For sockets you can do something similar, or you can place a SocketChannel in nonblocking mode to ensure it won't block. So, interrupting I/O doesn't make much use of interrupted() or InterruptedException, but it is possible, using modern JDKs.