How to stop a thread

Discussion in 'Java' started by Rick, Oct 5, 2003.

  1. Rick

    Rick Guest

    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
    Rick, Oct 5, 2003
    #1
    1. Advertising

  2. "Rick" <rrquick@nospam-com> wrote in message
    news:...
    > 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 http://www.iviz.com/
    Matt Humphrey, Oct 5, 2003
    #2
    1. Advertising

  3. Rick

    Roedy Green Guest

    On Mon, 06 Oct 2003 07:46:38 +1000, Rick <rrquick@nospam-com> wrote or
    quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Oct 5, 2003
    #3
  4. On 10/5/03 2:57 PM, in article
    Et0gb.35414$, "Matt Humphrey"
    <> wrote:

    > 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?
    Anthony Martin, Oct 6, 2003
    #4
  5. Rick

    Skippy Guest

    > > 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?


    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! :eek:)
    Skippy, Oct 6, 2003
    #5
  6. Rick

    Roedy Green Guest

    On Mon, 06 Oct 2003 00:01:17 GMT, Anthony Martin <*@martin-studio.com>
    wrote or quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Oct 6, 2003
    #6
  7. Rick

    VisionSet Guest

    "Anthony Martin" <*@martin-studio.com> wrote in message
    news:BBA5FEB3.60B3%*@martin-studio.com...
    > On 10/5/03 2:57 PM, in article
    > Et0gb.35414$, "Matt Humphrey"
    > <> wrote:
    >
    > > 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?


    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.

    --
    Mike W
    VisionSet, Oct 6, 2003
    #7
  8. On Mon, 06 Oct 2003 00:01:17 +0000, Anthony Martin wrote:

    > On 10/5/03 2:57 PM, in article
    > Et0gb.35414$, "Matt Humphrey"
    > <> wrote:
    >
    >> 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?


    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.
    Steve Horsley, Oct 6, 2003
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt Theule

    Stop Debugging doesn't stop in ASP.NET

    Matt Theule, Jul 23, 2003, in forum: ASP .Net
    Replies:
    7
    Views:
    728
    Matt Theule
    Jul 24, 2003
  2. Son KwonNam
    Replies:
    11
    Views:
    2,595
    mr_organic
    Apr 9, 2004
  3. Will
    Replies:
    1
    Views:
    15,220
    Thomas Weidenfeller
    Nov 2, 2004
  4. Benji
    Replies:
    34
    Views:
    1,172
    pkriens
    Oct 28, 2005
  5. Angus
    Replies:
    5
    Views:
    451
    Ben Bacarisse
    Jul 18, 2010
Loading...

Share This Page