«

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

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 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" <> wrote in message news:<t5-dnYWcp9ykk->...
> 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 wrote:
> "Chris Uppal" <> wrote in message
> news:<t5-dnYWcp9ykk->...
> > 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

Dave Monroe wrote:

> "Chris Uppal" <> wrote in message news:<t5-dnYWcp9ykk->...
>
>>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

>> 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 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 <> wrote in
news:AYBdc.65780$:

> 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