How to stop a thread without using stop()

Discussion in 'Java' started by Son KwonNam, Apr 8, 2004.

  1. Son KwonNam

    Son KwonNam Guest

    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.

    --
    ** Son KwonNam
    Please DO NOT reply to this message's email address.
    The address is fake.
     
    Son KwonNam, Apr 8, 2004
    #1
    1. Advertising

  2. Son KwonNam

    Chris Uppal Guest

    Son KwonNam wrote:

    > 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
     
    Chris Uppal, Apr 8, 2004
    #2
    1. Advertising

  3. On Thu, 08 Apr 2004 16:35:02 +0900, Son KwonNam wrote:
    > 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");
    }


    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Apr 8, 2004
    #3
  4. Son KwonNam

    Chris Uppal Guest

    Gordon Beaton wrote:

    > 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
     
    Chris Uppal, Apr 8, 2004
    #4
  5. Son KwonNam

    Dave Monroe Guest

    "Chris Uppal" <-THIS.org> wrote in message news:<>...
    > Son KwonNam wrote:
    >
    > > 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



    Not exactly true.

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

    The JVM handles the details.

    Dave Monroe
     
    Dave Monroe, Apr 9, 2004
    #5
  6. Son KwonNam

    Chris Uppal Guest

    Dave Monroe wrote:
    > "Chris Uppal" <-THIS.org> wrote in message
    > news:<>...
    > > Son KwonNam wrote:
    > >
    > > > 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

    >
    >
    > 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
     
    Chris Uppal, Apr 9, 2004
    #6
  7. Son KwonNam

    Rogan Dawes Guest

    Dave Monroe wrote:

    > "Chris Uppal" <-THIS.org> wrote in message news:<>...
    >
    >>Son KwonNam wrote:
    >>
    >>
    >>>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

    >
    >
    >
    > 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
    --
    Rogan Dawes
    nntp_AT_dawes*DOT*za-DOT-net
     
    Rogan Dawes, Apr 9, 2004
    #7
  8. Son KwonNam

    mr_organic Guest

    >> 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
     
    mr_organic, Apr 9, 2004
    #8
  9. mr_organic wrote:

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


    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.

    --
    Kind regards,
    Christophe Vanfleteren
     
    Christophe Vanfleteren, Apr 9, 2004
    #9
  10. Christophe Vanfleteren <> wrote in
    news:AYBdc.65780$-ops.be:

    > mr_organic wrote:
    >
    >>>> 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

    >
    > 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
     
    J. David Boyd, Apr 9, 2004
    #10
  11. J. David Boyd wrote:

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


    Exactly.

    There's more info on this here:
    http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

    --
    Kind regards,
    Christophe Vanfleteren
     
    Christophe Vanfleteren, Apr 9, 2004
    #11
  12. Son KwonNam

    mr_organic Guest

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


    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
     
    mr_organic, Apr 9, 2004
    #12
    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:
    740
    Matt Theule
    Jul 24, 2003
  2. Stephen Miller
    Replies:
    3
    Views:
    3,977
    Stephen Miller
    Jul 2, 2004
  3. Benji
    Replies:
    34
    Views:
    1,177
    pkriens
    Oct 28, 2005
  4. Rajshekhar
    Replies:
    5
    Views:
    2,159
    Jonathan Bartlett
    Mar 29, 2005
  5. Navin Mishra
    Replies:
    0
    Views:
    195
    Navin Mishra
    Mar 22, 2005
Loading...

Share This Page