Terminate a Thread

J

Jason Cavett

I am having a heck of a time terminating a running thread.

The class (Process) implements Runnable. When I hit cancel (in the
GUI - the GUI and process are running in separate threads), a method
in Process (cancel()) is called. Cancel sets status and does some
things so that the GUI is updated with the proper information. But,
the run() method still continues until completion. There are a number
of steps in the run method (10 in this case), but if I cancel, I want
it to stop immediately, so checking for a "cancel" flag before each
method call would not accomplish what I'm trying to achieve. Also, I
cannot seem to call this.interrupt() - presumably because Process
implements Runnable and does not extend Thread.

Any hints/clues/ideas on how to approach this problem?

Thank you.
 
T

Tom Hawtin

Jason said:
The class (Process) implements Runnable. When I hit cancel (in the

Calling a class by a name already used in java.lang isn't a great idea.
GUI - the GUI and process are running in separate threads), a method
in Process (cancel()) is called. Cancel sets status and does some
things so that the GUI is updated with the proper information. But,
the run() method still continues until completion. There are a number
of steps in the run method (10 in this case), but if I cancel, I want
it to stop immediately, so checking for a "cancel" flag before each
method call would not accomplish what I'm trying to achieve.

Then check the flag within each method.
Also, I
cannot seem to call this.interrupt() - presumably because Process
implements Runnable and does not extend Thread.

You can still call interrupt on the Thread that is running the task.
However, it will only interrupt on waits and possibly I/O. Of course, it
could interrupt, say, I/O involved with loading a class, making that
class forever inaccessible (through that ClassLoader).

Tom Hawtin
 
M

Mark Space

Jason said:
I am having a heck of a time terminating a running thread.

The class (Process) implements Runnable. When I hit cancel (in the
GUI - the GUI and process are running in separate threads), a method
in Process (cancel()) is called. Cancel sets status and does some
things so that the GUI is updated with the proper information. But,
the run() method still continues until completion.


What you describe here sounds suspiciously like "cooperative
multitasking." Basically, it doesn't work. Preempting a running
process on a CPU, when that process isn't being cooperative (i.e., not
checking it's flag) has been tried and is just a rickety pile of bricks.

There are a number
of steps in the run method (10 in this case), but if I cancel, I want
it to stop immediately, so checking for a "cancel" flag before each
method call would not accomplish what I'm trying to achieve. Also, I

Any reason why you can't use Threads? Of course, calling Thread stop()
could leave your application in an unworkable state. If all you are
doing is tear-down (the app is shutting down anyway), that may be ok.

Otherwise, my only idea is to use some native methods to make kernel
calls -- that's the only guy who can stop a run-away process.
 
C

christopher

you say you want the thread to stop -- why? Do you *need* the thread
to stop because it does things you don't want it to do, or are you
just annoyed that it doesn't perform as you would like it to?

If the process performs a task you do not want it to, check the cancel
flag before performing any such task:

boolean isRunning=true;
run(){
if(isRunning) doStepOne();
if(isRunning) doStepTwo();
}
void doStepTwo(){
if(isRunning) doCriticalTask;
}
void killMe(){
isRunning=false;
}


It it is an emotional 'want' (as it sounds to me) get on with the
job of writing the program. Elegance in code can't always be
achieved, and understanding the 'why' of thread performance (as the
other respondents have pointed out) will aid you in future code
design, so you don't have unreasonable requirements before you
understand the technical underpinnings.
 
T

Tris Orendorff

(e-mail address removed) burped up warm pablum in
If the process performs a task you do not want it to, check the cancel
flag before performing any such task:

boolean isRunning=true;
run(){
if(isRunning) doStepOne();
if(isRunning) doStepTwo();
}
void doStepTwo(){
if(isRunning) doCriticalTask;
}
void killMe(){
isRunning=false;
}

Should that be "volatile boolean isRunning=true;" up top?
 
J

Jason Cavett

you say you want the thread to stop -- why? Do you *need* the thread
to stop because it does things you don't want it to do, or are you
just annoyed that it doesn't perform as you would like it to?

If the process performs a task you do not want it to, check the cancel
flag before performing any such task:

boolean isRunning=true;
run(){
if(isRunning) doStepOne();
if(isRunning) doStepTwo();}

void doStepTwo(){
if(isRunning) doCriticalTask;}

void killMe(){
isRunning=false;

}

It it is an emotional 'want' (as it sounds to me) get on with the
job of writing the program. Elegance in code can't always be
achieved, and understanding the 'why' of thread performance (as the
other respondents have pointed out) will aid you in future code
design, so you don't have unreasonable requirements before you
understand the technical underpinnings.


The user can cancel the app at any time (during a process, before or
after a process). I don't want my app to continue. Maybe I'll just
let the IOException be thrown and hide it if the application is
cancelled in the middle of the process (as if everything went
smoothly).
 
J

Jason Cavett

What you describe here sounds suspiciously like "cooperative
multitasking." Basically, it doesn't work. Preempting a running
process on a CPU, when that process isn't being cooperative (i.e., not
checking it's flag) has been tried and is just a rickety pile of bricks.


Any reason why you can't use Threads? Of course, calling Thread stop()
could leave your application in an unworkable state. If all you are
doing is tear-down (the app is shutting down anyway), that may be ok.

Otherwise, my only idea is to use some native methods to make kernel
calls -- that's the only guy who can stop a run-away process.

Heh. It may be cooperative multitasking. Unfortunately, since the
application that does the "work" is separate from the "gui" - I pretty
much don't have a choice.

I might be able to use threads. Your post gave me an idea (run the
entire process within a thread and if cancel is selected just kill the
thread completely). I don't care what state my system is left in
since I have a clean-up method.

Alright, thank you for your help.
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top