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

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

Interrupt code while running (from Form)

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

Contents

  Interrupt code while running (from Form) jkl <euclidalgorithm@gmail.com> - 2016-10-20 01:44 -0700
    Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 10:33 +0100
    Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 05:27 -0700
      Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 16:01 +0100
        Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 08:47 -0700
          Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 17:49 +0100
            Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 10:17 -0700
              Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-21 15:38 +0100
                Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-21 16:38 +0100
          Re: Interrupt code while running (from Form) lewbloch@gmail.com - 2016-10-22 16:18 -0700

#35845 — Interrupt code while running (from Form)

Hi

Sorry for pretty basic question - I'm relearning.

I'm learning Java again after several years and running Netbeans.   I have a simple little form which I'm using to report the output of
prime numbers starting from an integer entered by the user, then the system counts up to another user defined number listing all the prime numbers in between.   Pretty simple stuff.

... The trouble is, even running in Netbeans, the only way to interrupt it while running is to go outside the form and use the Stop button in Netbeans IDE.   I have put a stop button on the form but however many times I click it while the code's running - it's being ignored.

This is all OO stuff so I'm assuming there's no way within the body of the code I can check for the stop button being pressed.

I'm missing something fundamental - but can't think what.

Cheers

[toc] | [next] | [standalone]

#35846

On 20/10/16 09:44, jkl wrote:
> Hi
>
> Sorry for pretty basic question - I'm relearning.
>
> I'm learning Java again after several years and running Netbeans.   I have a simple little form which I'm using to report the output of
> prime numbers starting from an integer entered by the user, then the system counts up to another user defined number listing all the prime numbers in between.   Pretty simple stuff.
>
> ... The trouble is, even running in Netbeans, the only way to interrupt it while running is to go outside the form and use the Stop button in Netbeans IDE.   I have put a stop button on the form but however many times I click it while the code's running - it's being ignored.
>
> This is all OO stuff so I'm assuming there's no way within the body of the code I can check for the stop button being pressed.
>
> I'm missing something fundamental - but can't think what.

I would guess that you are missing the fact that if you execute any long-running method on the EDT (Event Dispatch Thread) then the UI will not be able process any events.
It's not about Java or OO, it's about understanding how Swing threads and events work.

I recommend that you read the Java tutorial on Swing: http://docs.oracle.com/javase/tutorial/uiswing/index.html
In particular, if you want to run background/concurrent tasks then it's vital that you read the chapter on Concurrency in Swing;
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

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

#35848

On Thursday, October 20, 2016 at 4:45:19 AM UTC-4, jkl wrote:
> ... The trouble is, even running in Netbeans, the only way to interrupt it while running is to go outside the form and use the Stop button in Netbeans IDE.   I have put a stop button on the form but however many times I click it while the code's running - it's being ignored.
> 

I don't use Netbeans but to stop a background thread normally you interrupt it, then it has to care that it's interrupted..

          Thread rt = new Thread() {
               int count = 0;
               @Override
               public void run() {
                    while (true) {
                         if (Thread.interrupted()) {
                              break;
                         }
                         if (count == Integer.MAX_VALUE) {
                              count = 0;
                         } else {
                              count++;
                         }
                         System.out.println(count);
                    }
               }
          };
          JFrame f = new JFrame();
          f.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
          JButton b = new JButton("Stop it");
          f.getContentPane().add(b);
          rt.start();
          b.addActionListener(new ActionListener() {
               @Override
               public void actionPerformed(ActionEvent arg0) {
                    rt.interrupt();
               }
          });
          f.pack();
          f.setVisible(true);

If you run something from the IDE then you think you closed out but the IDE shows your test still running, go to your JDK install folder, to it's bin folder, and run the jvisualvm.exe.  Double click your process, go to the Threads tab, and click the Thread Dump button.

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

#35851

On 20/10/16 13:27, Eric Douglas wrote:
> If you run something from the IDE then you think you closed out but the IDE shows your test still running, go to your JDK install folder, to it's bin folder, and run the jvisualvm.exe.  Double click your process, go to the Threads tab, and click the Thread Dump button.

To perform background tasks in a Swing application it's preferable to use a SwingWorker. It takes care of worker thread management for you so you shouldn't get problems like this (the worker threads are daemons). It also has other advantages if any UI feedback is required.

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

#35852

On Thursday, October 20, 2016 at 11:02:02 AM UTC-4, Nigel Wade wrote:
> To perform background tasks in a Swing application it's preferable to use a SwingWorker. It takes care of worker thread management for you so you shouldn't get problems like this (the worker threads are daemons). It also has other advantages if any UI feedback is required.

I'm not sure what you mean by the thread management.  As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.

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

#35853

On 20/10/16 16:47, Eric Douglas wrote:
> On Thursday, October 20, 2016 at 11:02:02 AM UTC-4, Nigel Wade wrote:
>> To perform background tasks in a Swing application it's preferable to use a SwingWorker. It takes care of worker thread management for you so you shouldn't get problems like this (the worker threads are daemons). It also has other advantages if any UI feedback is required.
>
> I'm not sure what you mean by the thread management.

Thread management is the bit you've got wrong if you need to resort to jvisualvm to see why your program didn't finish.
You've failed to manage the lifecycle of your threads, and some are still running, preventing the JVM from exiting cleanly.

> As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.
>

It's [almost] necessary when doing that, but there's no reason you can't use it for any other background tasks in a Swing GUI application.
The lifecycle methods in SwingWorker integrate very well with an event driven GUI. Otherwise you have to do everything manually, and if you get it wrong you end up messing with jvisualvm, or TaskManger or Ctrl-C to end your errant process/threads.

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

#35854

On Thursday, October 20, 2016 at 12:49:59 PM UTC-4, Nigel Wade wrote:
> 
> Thread management is the bit you've got wrong if you need to resort to jvisualvm to see why your program didn't finish.
> You've failed to manage the lifecycle of your threads, and some are still running, preventing the JVM from exiting cleanly.
> 

jvisualvm is the last resort debugger tool when you don't know what you did wrong.  I posted an example of one using simple Thread methods that does exit cleanly.  I'm asking you to show how SwingWorker makes that better.

> > As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.
> >
> 
> It's [almost] necessary when doing that, but there's no reason you can't use it for any other background tasks in a Swing GUI application.
> The lifecycle methods in SwingWorker integrate very well with an event driven GUI. Otherwise you have to do everything manually, and if you get it wrong you end up messing with jvisualvm, or TaskManger or Ctrl-C to end your errant process/threads.

There's no reason you can't use a car for every trip you take, even if you're only going next door.  Yes the SwingWorker can start literally every thread, many times it's just unnecessary.
You can kick off a background thread using a Runnable, and it can kick off a GUI task using SwingUtilities.invokeLater (or EventQueue.invokeLater) but it is just easier to use the SwingWorker when you know you might need both background and GUI, and it's particularly helpful when they're simultaneous (ie updating progress bar).

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

#35857

On 20/10/16 18:17, Eric Douglas wrote:
> On Thursday, October 20, 2016 at 12:49:59 PM UTC-4, Nigel Wade wrote:
>>
>> Thread management is the bit you've got wrong if you need to resort to jvisualvm to see why your program didn't finish.
>> You've failed to manage the lifecycle of your threads, and some are still running, preventing the JVM from exiting cleanly.
>>
>
> jvisualvm is the last resort debugger tool when you don't know what you did wrong.  I posted an example of one using simple Thread methods that does exit cleanly.  I'm asking you to show how SwingWorker makes that better.

There are examples in the tutorial. I provided the link in my first post on this thread.

Quite simply, SwingWorker manages the thread life-cycle for you. It creates the thread when you execute() your SwingWorker, then takes care of running its doInBackground() method. It executes a thread-safe method to process intermediate results and, on termination, has a thread-safe method to return a final result. When your program exits it doesn't block if the thread has not completed.


>
>>> As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.
>>>
>>
>> It's [almost] necessary when doing that, but there's no reason you can't use it for any other background tasks in a Swing GUI application.
>> The lifecycle methods in SwingWorker integrate very well with an event driven GUI. Otherwise you have to do everything manually, and if you get it wrong you end up messing with jvisualvm, or TaskManger or Ctrl-C to end your errant process/threads.
>
> There's no reason you can't use a car for every trip you take, even if you're only going next door.

Huh?

> Yes the SwingWorker can start literally every thread, many times it's just unnecessary.

Unnecessary? In Swing applications it's easier, cleaner, and works. Sure you can roll your own threads if you want to. You can roll your own code for doing pretty much anything for which convenience classes exist. It doesn't mean you should, or that you have to.

> You can kick off a background thread using a Runnable, and it can kick off a GUI task using SwingUtilities.invokeLater (or EventQueue.invokeLater) but it is just easier to use the SwingWorker when you know you might need both background and GUI, and it's particularly helpful when they're simultaneous (ie updating progress bar).
>

But SwingWorker does it all for you, and doesn't hang your process when the EDT finishes. What reason is there not to use it?

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

#35858

On 21/10/16 15:38, Nigel Wade wrote:
> But SwingWorker does it all for you, and doesn't hang your process when the EDT finishes. What reason is there not to use it?

I should have added that SwingWorker implements the Future interface.
For none Swing applications the equivalent class to use would be FutureTask.

For the masochists there's always the "Good Old Days" of multi-threaded C programming in X/Motif applications using an implementation of threads which pre-dates POSIX pthreads. Passing events from your own threads to the Motif event loop was always good bit of fun for late on a Friday afternoon.

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

#35861

On Thursday, October 20, 2016 at 8:47:32 AM UTC-7, Eric Douglas wrote:
> On Thursday, October 20, 2016 at 11:02:02 AM UTC-4, Nigel Wade wrote:
> > To perform background tasks in a Swing application it's preferable to use a SwingWorker. It takes care of worker thread management for you so you shouldn't get problems like this (the worker threads are daemons). It also has other advantages if any UI feedback is required.
> 
> I'm not sure what you mean by the thread management.  As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.

SwingWorker is necessary to separate business logic from GUI acts. It has nothing to do with daemon threads.

[toc] | [prev] | [standalone]

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

csiph-web