How to stop a thread

[Rick]

Hi,

If suspend(), stop() and destroy() are depricated methods.. what is the
best way to stop a running thread? Should I use interrupt()? Or should I
null it out? For example:

Thread t = new Thread();
t.start();

....

t = null;

Thanks

Rick

 

[Matt Humphrey]

Hi,

If suspend(), stop() and destroy() are depricated methods.. what is the
best way to stop a running thread? Should I use interrupt()? Or should I
null it out? For example:

Thread t = new Thread();
t.start();

...

t = null;

The best way is for your thread method to periodically check a boolean
"stopRequest" and to clean its self up when it becomes true. The whole
reason why stop/suspend are deprecated is that only the thread itself knows
when it is safe to stop and knows how to clean things up. Be sure your flag
is marked volatile or is otherwise properly synchronized. BTW setting your
thread handle to null will not have any effect.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Roedy Green]

If suspend(), stop() and destroy() are depricated methods.. what is the
best way to stop a running thread? Should I use interrupt()? Or should I
null it out? For example:

See StoppableThread. Source is part of the business package available
from http://mindprod.com/products.html#BUS

Basically you set a boolean that the thread you want to stop looks at
periodically at convenient times, and shuts itself down gracefully.

 

[Anthony Martin]

BTW setting your
thread handle to null will not have any effect.

Since we're doing BTWs, I've read that you shoudn't extend Thread. Instead,
you should *always* implement Runnable. That's what I usually do, but is
there any rational to this?

 

[Skippy]

BTW setting your

Since we're doing BTWs, I've read that you shoudn't extend Thread. Instead,
you should *always* implement Runnable. That's what I usually do, but is
there any rational to this?

I think only from a OO point-of-view:

Extending Thread means that you add functionality to that class. Since you
only use it, subclassing makes no sense. Use the Runnable-interface to tell
the Thread what to do.

Why OO?
Imagine you have to learn a kid how to read. You can tell it how to read, or
create a kid that reads, but only that. Now get that kid to write. Teach it
or create a new kid?

I hope this makes sense to you! )

 

[Roedy Green]

I've read that you shoudn't extend Thread. Instead,
you should *always* implement Runnable. That's what I usually do, but is
there any rational to this?

Are you truly inventing a new flavour of Thread, or just creating an
instance of something to run? StoppableThread extends Thread, but
most other things would just implement Runnable.

 

[VisionSet]

Since we're doing BTWs, I've read that you shoudn't extend Thread. Instead,
you should *always* implement Runnable. That's what I usually do, but is
there any rational to this?

One good reason is that you can then subclass whatever you like.
And since a (runnable) object typically 'has a' thread, this makes more
sense from a design perspective. The general rule that composition should
be chosen over inheritence.

 

[Steve Horsley]

Since we're doing BTWs, I've read that you shoudn't extend Thread.
Instead, you should *always* implement Runnable. That's what I usually
do, but is there any rational to this?

I think the best reason is that it avoids confusion. I've seen people
extend Thread, fill it full of variables and methods that have nothing to
do with being a Thread, then they start multithreading, and get very
confused about what happens then one thread is calling another thread's
methods, who is interrupting who, who is synchronizing on what etc.

It seems to me to be much cleaner and easier to compartmentalise to have
all the program login in a Runnable object, and just have it visited by
threads in the same way that clerks visit a filing cabinet. You don't want
to be confused by the fact that a particular clerk owns a particular
filing cabinet, let alone the idea that a clerk IS a filing cabinet.

Steve.