How to stop a thread without using stop()

S

Son KwonNam

There is a thread which calls just ONE METHOD.

The problem is the method can work for 1 sec to more than 10minutes.
I have to stop if the thread work for more than 10 secs and I don't have
the source of the method - but, I have to use the method.

Thread.stop() method is deprecated..
So, I tried using interrupt() method, but it did not work.

Then how can the thread be stopped without using stop() ??

Thank you.
 
C

Chris Uppal

Son said:
The problem is the method can work for 1 sec to more than 10minutes.
I have to stop if the thread work for more than 10 secs and I don't have
the source of the method - but, I have to use the method.

Then how can the thread be stopped without using stop() ??

System.exit() ?

Seriously, I don't think there is a way.

-- chris
 
G

Gordon Beaton

There is a thread which calls just ONE METHOD.

The problem is the method can work for 1 sec to more than 10minutes.
I have to stop if the thread work for more than 10 secs and I don't have
the source of the method - but, I have to use the method.

Thread.stop() method is deprecated..
So, I tried using interrupt() method, but it did not work.

Then how can the thread be stopped without using stop() ??

I'll agree with Chris here, there really is no way to stop the thread.

However maybe you don't actually need to stop it. Depending on what
it's doing, maybe it's sufficient to stop waiting for the results of
the operation (and let the thread finish on its own). After your
timeout, simply accept that the operation has taken too long and get
on with whatever else you're doing.

The following is completely untested:

public class MyRunnable {
private resultType result = null;

/* perform some long operation */
public void run() {
setResult(sometimesReallyLongOperation());
}

/* set result, notify waiting thread if any */
private synchronized void setResult(resultType result) {
this.result = result;
notify();
}

/* wait at most timeout ms for result */
public synchronized resultType getResult(long timeout) throws MyTimeoutException {
long now = System.currentTimeMillis();
long stop = now + timeout;

while ((result == null) && (stop > now )) {
wait(stop - now);
now = System.currentTimeMillis();
}

if (result == null) {
/* alternative: return default value instead of exception */
throw new MyTimeoutException("gurgle");
}
return result;
}
}


In the main program:

resultType result = null;
Runnable r = new MyRunnable(foo);
Thread t = new Thread(r);
t.start();

try {
result = r.getResult(10000); // wait max 10 seconds
}
catch (MyTimeoutException e) {
System.out.println("operation timed out");
}
 
C

Chris Uppal

Gordon said:
However maybe you don't actually need to stop it. Depending on what
it's doing, maybe it's sufficient to stop waiting for the results of
the operation (and let the thread finish on its own).

A minor improvement to this would be to use two threads instead of one.

Start a thread which:
a) starts a sub-thread to run the problem code, ensuring that the sub-thread is
created as a daemon thread.
b) uses Gordon's idea to wait for a maximum of 10 secs (or whatever) for the
sub-thread.
c) if the sub-thread hasn't finished by that time then it sets the sub-thread's
priority really low.
d) exits normally (possibly leaving the sub-thread to churn uselessly).

That would have the advantages that:
a) your main code doesn't "know" about the mess trying to control the problem
method.
b) your application would exit without being kept alive by any remaining
sub-threads (since they are daemons, the JVM doesn't wait for them to finish).
c) you can reduce the drain on CPU caused by the useless-but-unstoppable
sub-threads.

Not pretty, not pretty at all...

-- chris
 
D

Dave Monroe

Chris Uppal said:
System.exit() ?

Seriously, I don't think there is a way.

-- chris


Not exactly true.

If you do a 'return' to the run() method, that stops the thread.

The JVM handles the details.

Dave Monroe
 
C

Chris Uppal

Dave said:
Not exactly true.

If you do a 'return' to the run() method, that stops the thread.

Yes of course, but the OP's question was how to stop the thread *when the run
method does not return*.

-- chris
 
R

Rogan Dawes

Dave said:
Not exactly true.

If you do a 'return' to the run() method, that stops the thread.

The JVM handles the details.

Dave Monroe

Of course, that is the obvious way, but if you don't have the source of
the method (as the original poster indicated), then it can be tricky to
get it to return() when you want it to sometimes . . .

Regards,

Rogan
 
M

mr_organic

If you do a 'return' to the run() method, that stops the thread.
Yes of course, but the OP's question was how to stop the thread *when
the run method does not return*.

-- chris

If you keep a reference to the thread id (a numeric, I think), you should
be able to kill() that thread, yes? So you put a timer or a semaphore on
the thread, and if it doesn't complete within the given parameters, you
issue a kill().

mr_organic
 
C

Christophe Vanfleteren

mr_organic said:
If you keep a reference to the thread id (a numeric, I think), you should
be able to kill() that thread, yes? So you put a timer or a semaphore on
the thread, and if it doesn't complete within the given parameters, you
issue a kill().

mr_organic

That might be kind of hard to do, considering that Thread does not have a
kill() method.
It does have a destroy() method, but that has never been implemented.
 
J

J. David Boyd

That might be kind of hard to do, considering that Thread does not
have a kill() method.
It does have a destroy() method, but that has never been implemented.


Even if it did, what about lost resources or indeterminate state? Isn't
that the reason that stop() was deprecated in the first place?

Dave
 
M

mr_organic

If you keep a reference to the thread id (a numeric, I think), you
That might be kind of hard to do, considering that Thread does not
have a kill() method.
It does have a destroy() method, but that has never been implemented.

Ah, I meant destroy() rather than kill(). I didn't know that it was
unimplemented, though. Why put the API in there and then tell people not
to use it? Same goes for stop(), etc. Seems like a pretty crappy thread
API design to me if that's the case -- it sounds like the designers of
the threading API were counting on underlying POSIX semantics (a la
Solaris) everywhere, but found that these semantics didn't translate well
to WIN32 threads (or other non-POSIX threading models, for that matter).

*shrug*

One of the reasons I liked the C-based select() method better than
threads (Java-based or otherwise) was because it avoided all the hellish
problems of threads -- races, deadlocks, all the rest -- and still gave
you most of the concurrency benefits (albeit not with multi-CPU ability).
I think programmers are too quick to use threads when other concurrency
methods would work just as well, and far more simply.

FWIW.

mr_organic
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top