Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36957 > unrolled thread

How do I automatically cleanly terminate a thread?

Back to article view | Back to comp.lang.java.programmer

Contents

  How do I automatically cleanly terminate a thread? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-17 08:06 -0700
    Re: How do I automatically cleanly terminate a thread? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-17 11:27 -0400
      Re: How do I automatically cleanly terminate a thread? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-17 09:03 -0700
        Re: How do I automatically cleanly terminate a thread? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-07-17 11:53 -0500
          Re: How do I automatically cleanly terminate a thread? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-17 10:05 -0700
            Re: How do I automatically cleanly terminate a thread? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-17 18:16 +0000
              Re: How do I automatically cleanly terminate a thread? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-17 12:18 -0700
                Re: How do I automatically cleanly terminate a thread? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-17 16:05 -0400
            Re: How do I automatically cleanly terminate a thread? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-07-17 13:29 -0500
        Re: How do I automatically cleanly terminate a thread? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-17 13:05 -0400

#36957 — How do I automatically cleanly terminate a thread?

I invoke my main test thread.
This test thread creates a new instance of TestClassOne.
TestClassOne creates a new instance of WatchService.
TestClassOne starts a new thread to sit in the background and wait indefinitely.
(https://docs.oracle.com/javase/7/docs/api/java/nio/file/WatchService.html#take())
Main test thread loses reference to it's instance of TestClassOne (variable set to null).  Background thread keeps running.
Instance of TestClassOne should get garbage collected?  Can we automatically interrupt the background thread?

[toc] | [next] | [standalone]

#36958

On 7/17/2017 11:06 AM, Eric Douglas wrote:
> I invoke my main test thread.
> This test thread creates a new instance of TestClassOne.
> TestClassOne creates a new instance of WatchService.
> TestClassOne starts a new thread to sit in the background and wait indefinitely.
> (https://docs.oracle.com/javase/7/docs/api/java/nio/file/WatchService.html#take())
> Main test thread loses reference to it's instance of TestClassOne (variable set to null).  Background thread keeps running.
> Instance of TestClassOne should get garbage collected?  Can we automatically interrupt the background thread?

     The JVM holds references to all running threads: They won't become
garbage simply because your code forgets about them.  Also, a running
thread wouldn't stop even if it did somehow become garbage; that would
be subject to all the problems that cause Thread::stop and kin to be
deprecated.

     The only safe way to stop a thread is with its cooperation.  The
stopper arranges some mutually agreed-upon "Please stop soon" signal,
like a `volatile boolean' that the stoppee tests now and then.  Maybe
the stopper also arranges to awaken the stoppee if it might be in a
lengthy wait of some kind: It might interrupt the stoppee, or close
the socket the stoppee is using, or something of that kind -- whatever
will break the waiting thread out of its wait.

     If all you need is that the thread goes away in order to allow the
JVM to terminate, it may be simplest to make it a daemon: Call its
setDaemon(true) method before calling start().  The JVM assumes that
it's all right to clobber daemon threads when shutting down, the idea
being that if the asynchronous shutdown causes corruption it won't
matter because the whole Java environment is about to disappear.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred eighty-three days to go.

[toc] | [prev] | [next] | [standalone]

#36959

On Monday, July 17, 2017 at 11:27:46 AM UTC-4, Eric Sosman wrote:
>      If all you need is that the thread goes away in order to allow the
> JVM to terminate, it may be simplest to make it a daemon: Call its
> setDaemon(true) method before calling start().  The JVM assumes that
> it's all right to clobber daemon threads when shutting down, the idea
> being that if the asynchronous shutdown causes corruption it won't
> matter because the whole Java environment is about to disappear.
> 

So my main thread kicks off this process from a JButton action.  I declared it a daemon thread and it did auto terminate when the last GUI object was destroyed without calling it's proper close method.  That thread was sitting on the take() method and it printing something in the InterruptedException section which never printed.  So if we let the JVM terminate it with the daemons can I assume that's ok on a method like this?

[toc] | [prev] | [next] | [standalone]

#36960

On 7/17/2017 11:03, Eric Douglas wrote:
> On Monday, July 17, 2017 at 11:27:46 AM UTC-4, Eric Sosman wrote:
>>       If all you need is that the thread goes away in order to allow the
>> JVM to terminate, it may be simplest to make it a daemon: Call its
>> setDaemon(true) method before calling start().  The JVM assumes that
>> it's all right to clobber daemon threads when shutting down, the idea
>> being that if the asynchronous shutdown causes corruption it won't
>> matter because the whole Java environment is about to disappear.
>>
> 
> So my main thread kicks off this process from a JButton action.  I declared it a daemon thread and it did auto terminate when the last GUI object was destroyed without calling it's proper close method.  That thread was sitting on the take() method and it printing something in the InterruptedException section which never printed.  So if we let the JVM terminate it with the daemons can I assume that's ok on a method like this?
> 

Why don't you interrupt the thread as part of the shutdown process and 
then it will print your message in the catch section.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#36961

On Monday, July 17, 2017 at 12:54:06 PM UTC-4, Knute Johnson wrote:
> 
> Why don't you interrupt the thread as part of the shutdown process and 
> then it will print your message in the catch section.
> 

That's what I was trying to do but I created this from a GUI object.  Normally the JVM terminates when the last GUI object is destroyed but this thread stays active (if it's not a daemon).  I was wondering if there's a way to let it know it can interrupt it's own thread rather than having to remember to call a close method to interrupt it's thread from the windowClosing method.

[toc] | [prev] | [next] | [standalone]

#36963

On Mon, 17 Jul 2017 10:05:07 -0700, Eric Douglas wrote:

> That's what I was trying to do but I created this from a GUI object. 
> Normally the JVM terminates when the last GUI object is destroyed but
> this thread stays active (if it's not a daemon).  I was wondering if
> there's a way to let it know it can interrupt it's own thread rather
> than having to remember to call a close method to interrupt it's thread
> from the windowClosing method.
>
IIRC you said that the reference to the thread is lost so it can't be 
shut down. Is there no way this could be preserved, maybe with an 
extended JButton that triggers the thread by calling a method in your 
Model? 

This would mean you could keep the thread reference so that your shutdown 
code can terminate it cleanly. 

Alternatively, an extended JButton might pass the thread a reference to a 
variable used by shutdown code to tell the thread to terminate.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36965

On Monday, July 17, 2017 at 2:20:21 PM UTC-4, Martin Gregorie wrote:
> >
> IIRC you said that the reference to the thread is lost so it can't be 
> shut down. Is there no way this could be preserved, maybe with an 
> extended JButton that triggers the thread by calling a method in your 
> Model? 
> 
> This would mean you could keep the thread reference so that your shutdown 
> code can terminate it cleanly. 
> 
> Alternatively, an extended JButton might pass the thread a reference to a 
> variable used by shutdown code to tell the thread to terminate.
> 

I did create a close method I can call from the windowClosing method which does send the interrupt to the background thread monitoring for file changes.  That's the simple answer.

I was wondering if I put this in an API and someone else tries to implement it and doesn't call the close method for any reason can I get the background thread to terminate itself.  So far our only answer is it should be safe to kill a WatchService sitting on a take() method by running it in a daemon thread.

Ending the GUI terminates the JVM if there are no background (non-daemon) threads running.  I didn't see any clean way to trigger this condition to interrupt the thread other than manually calling a method.  I had tested setting the reference to null to see if the garbage collector would fire it.

[toc] | [prev] | [next] | [standalone]

#36966

On 7/17/2017 3:18 PM, Eric Douglas wrote:
> On Monday, July 17, 2017 at 2:20:21 PM UTC-4, Martin Gregorie wrote:
>>>
>> IIRC you said that the reference to the thread is lost so it can't be
>> shut down. Is there no way this could be preserved, maybe with an
>> extended JButton that triggers the thread by calling a method in your
>> Model?
>>
>> This would mean you could keep the thread reference so that your shutdown
>> code can terminate it cleanly.
>>
>> Alternatively, an extended JButton might pass the thread a reference to a
>> variable used by shutdown code to tell the thread to terminate.
>>
> 
> I did create a close method I can call from the windowClosing method which does send the interrupt to the background thread monitoring for file changes.  That's the simple answer.
> 
> I was wondering if I put this in an API and someone else tries to implement it and doesn't call the close method for any reason can I get the background thread to terminate itself.  So far our only answer is it should be safe to kill a WatchService sitting on a take() method by running it in a daemon thread.

     Note that the daemon thread will continue to run until the JVM
decides to shut down.  That might not be for a l-o-n-g time ...

> Ending the GUI terminates the JVM if there are no background (non-daemon) threads running.  I didn't see any clean way to trigger this condition to interrupt the thread other than manually calling a method.  I had tested setting the reference to null to see if the garbage collector would fire it.

     I haven't tried this myself, but for belt-AND-suspenders safety
you might give the users of your API not a reference to your Thread,
but to some kind of proxy object (probably a good idea in any case).
You'd make sure to keep no hard references to the proxy, but only a
WeakReference registered with a ReferenceQueue.  An auxiliary Thread
would wait for notification that the proxy object has become garbage,
and upon such notice would arrange for the two Threads to terminate,
just as if your client had actually remembered to call stopItPlease().

     ... but if you're trying to defend against misuse of your API,
bear in mind that fools can always outsmart the foolproof.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred eighty-three days to go.

[toc] | [prev] | [next] | [standalone]

#36964

On 7/17/2017 12:05, Eric Douglas wrote:
> On Monday, July 17, 2017 at 12:54:06 PM UTC-4, Knute Johnson wrote:
>>
>> Why don't you interrupt the thread as part of the shutdown process and
>> then it will print your message in the catch section.
>>
> 
> That's what I was trying to do but I created this from a GUI object.  Normally the JVM terminates when the last GUI object is destroyed but this thread stays active (if it's not a daemon).  I was wondering if there's a way to let it know it can interrupt it's own thread rather than having to remember to call a close method to interrupt it's thread from the windowClosing method.
> 

If I want to shutdown a thread before the GUI terminates I usually 
create a stop method that terminates all the threads that need to be 
stopped before the GUI.  If they are threads that can just be killed, I 
make them daemon threads and ignore them.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#36962

On 7/17/2017 12:03 PM, Eric Douglas wrote:
> On Monday, July 17, 2017 at 11:27:46 AM UTC-4, Eric Sosman wrote:
>>       If all you need is that the thread goes away in order to allow the
>> JVM to terminate, it may be simplest to make it a daemon: Call its
>> setDaemon(true) method before calling start().  The JVM assumes that
>> it's all right to clobber daemon threads when shutting down, the idea
>> being that if the asynchronous shutdown causes corruption it won't
>> matter because the whole Java environment is about to disappear.
>>
> 
> So my main thread kicks off this process from a JButton action.  I declared it a daemon thread and it did auto terminate when the last GUI object was destroyed without calling it's proper close method.  That thread was sitting on the take() method and it printing something in the InterruptedException section which never printed.  So if we let the JVM terminate it with the daemons can I assume that's ok on a method like this?

     The JVM happily clobbers daemon threads at shutdown.
It doesn't interrupt them, it just clobbers them, axes them,
kills them, deletes them, maims them, annihilates them, gives
them the old heave-ho, and nukes the vestigial remnants.

     If you want an InterruptedException, use Thread::interrupt.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred eighty-three days to go.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web