«

Lee Francis Wilhelmsen wrote:

> Does this look ok? I'm having trouble getting the Worker.doWork() algorithm
> to terminiate it's operation? I'm thinking fairly general here. The
> algorithm contains a loop. Should each iteration check Thread.interrupted()
> and break if true? Should it throw an InterruptedException? Both (depending
> the thread state)

What you've posted looks fine -- but the important part is how you're
handling the interrupt, and that you didn't bother to post.

Note that setting the Thread to null doesn't particularily help to kill
off the thread. A ThreadGroup object will still hold a reference to the
thread so long as it's alive, so setting it to null in your MyClass
isn't going to cause it to be marked for garbage collection
automatically (it's still not a bad idea to do -- it just doesn't help
kill the thread).

If your loop is running a lengthy operation, then yes -- it should
regularily check to see wether or not it's been interrupted. Otherwise
it will continue to run. Depending on wether or not any cleanup is
necessary, you can either break out of the loop (ensuring that by doing
so you're not going to fall into another loop...), or simply return
(which causes an immediate end to the thread).

HTH!

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org

Hi Brad, and thanks for answering.

"Brad BARCLAY" <> wrote:
> Lee Francis Wilhelmsen wrote:
>
> > Does this look ok? I'm having trouble getting the Worker.doWork()
algorithm
> > to terminiate it's operation? I'm thinking fairly general here. The
> > algorithm contains a loop. Should each iteration check
Thread.interrupted()
> > and break if true? Should it throw an InterruptedException? Both
(depending
> > the thread state)
>
> What you've posted looks fine -- but the important part is how you're
> handling the interrupt, and that you didn't bother to post.

Well the algorithm just performs a Thread.interrupted() at intervals. If
true then it returns, else it carries on. However, this isn't working as
interrupted() never seems returns true.

I've even tried to give the thread a name, then perform something like

Thread t = Thread.currentThread();
System.out.println(t.getName());

just to make sure that it's the same thread (it is) and then

if (t.isInterrupted()) {
return;
}

This isn't working either.

Is there an explaination for why isInterrupted() or interrupted() never are
true when a interrupt() request has been posted?

I might add that code that the algorithm calls also is using threaded code
(deep down), but this works as predicted and is never referenced in the
algorithm. I don't know if this matters.

regards
Lee Francis

Lee Francis Wilhelmsen wrote:

> Well the algorithm just performs a Thread.interrupted() at intervals. If
> true then it returns, else it carries on. However, this isn't working as
> interrupted() never seems returns true.
>
> I've even tried to give the thread a name, then perform something like
>
> Thread t = Thread.currentThread();
> System.out.println(t.getName());
>
> just to make sure that it's the same thread (it is) and then
>
> if (t.isInterrupted()) {
> return;
> }
>
> This isn't working either.

Are you making any calls to wait() or the like, or are making any
method calls that block with a wait() in them? In such a case, they may
be catching InterruptedException. If they are using interrupted(),
they'll clear the interrupted state, so you may never be seeing it in
your own code.

That's just a guess -- I'd probably need to see the entire code to
debug a problem like this.

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org