5

It is a widely known fact that one shall not stop running processes using Thread.stop().

Usually the manuals and tutorials suggest using Thread.interrupt() or some boolean variable instead, and checking from inside the code for that interrupt or variable.

But if I have a library method which takes a very long time to execute sometimes, and I want to give user an ability to stop that process? And library does not give me a mechanisms to do it (does not check thread interrupted status, and no "stop!" variables)?

And, to add to the bad things, there is either no source code for library, or it is just too big to edit it and add checks at appropriate places.

It seems that Thread.stop() is the only solution here. Or maybe there is some workaround?

Rogach
  • 26,050
  • 21
  • 93
  • 172

5 Answers5

4

Why you do not try to use sleep(long timeout) when are waiting for some condition and if had not success, you simple "return" from the thread?

Probably your thread is running in a while (booleanVariable) { },

if it is, you could set this variable as volatile, and the thread controller set it as false.

Think of the Thread.stop() like the System.exit(value), it works, but when you have some bug making you thread stop/vm exit, will be much more harder to find it out.

zwol
  • 135,547
  • 38
  • 252
  • 361
Pih
  • 2,282
  • 15
  • 20
  • FYI, your edit suggestion was rejected because you edited an answer of your own into someone else's answer. I've taken the liberty of adding it to this answer, instead. – zwol Apr 26 '11 at 17:57
  • Sorry, I tried to edit my own question. I am needing a bit more of practice on stackoverflow. Sorry :-) – Pih Apr 26 '11 at 18:01
  • No worries. Everyone was new to the site once. – zwol Apr 26 '11 at 18:03
3

If practical in your situation, spawn another process and treat that as the unit of work, rather than a thread. Process killing is much more deterministic, though devoting a process to what used to be a thread's work might be too heavyweight for your situation.

jlew
  • 10,491
  • 1
  • 35
  • 58
  • Yes, that's a good alternative. But spawning another process (with exec(), I assume?) is not crossplatform and can be really heavyweight in Java - it will eat ~100 Mb of memory just to launch another JVM. Am I right? – Rogach Apr 26 '11 at 18:18
  • Additionaly, it is probably not possible in applet enviroment. – Rogach Apr 26 '11 at 18:18
1

The only solution better than using Thread.stop() is to use the library in a seperate thread which you can kill to stop it.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • And how does one kill a thread? – Rogach Apr 26 '11 at 17:43
  • It triggers the Thread to throw a ThreadDeath error, which should unwind locks and method calls and silently ignores the Error. The reason its not safe is that it can occur anywhere in code which can leave things in a bad state. – Peter Lawrey Apr 26 '11 at 19:13
1

You may want to look for different handles of the function you are running, for example if its IO you can try to close any open connections/streams. If you are stuck with this library (IE can't find one that has better interruption mechanics) Thread.stop() is your only way of stopping the thread.

John Vint
  • 39,695
  • 7
  • 78
  • 108
0

Thread.stop() is deprecated from java 4 onwards..I read an article to stop a thread by wrapping the call to the library in an separate class that implements InterruptibleChannel which is part of java.nio. Interruptibleclasses has close() method, through which another thread can call it asynchronously.

prem sagar
  • 1
  • 3