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

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

Re: polling IRQs in a thread's code

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: polling IRQs in a thread's code "John B. Matthews" <nospam@nospam.invalid> - 2013-03-24 22:57 -0400
    Re: polling IRQs in a thread's code markspace <markspace@nospam.nospam> - 2013-03-24 21:16 -0700

#23108 — Re: polling IRQs in a thread's code

In article <thread-20130324233549@ram.dialup.fu-berlin.de>,
 ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>   The user can request the thread to end using a GUI button.
>   The thread has to check often whether the user has requested
>   this, and then has to stop.

Also consider SwingWorker<T,V>. You can publish intermediate 
results from within your implementation of doInBackground() and 
reliably update the GUI from process(), which executes on the EDT. 
This related example also illustrates using cancel():

<https://sites.google.com/site/drjohnbmatthews/randomdata>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [next] | [standalone]

#23109

On 3/24/2013 7:57 PM, John B. Matthews wrote:

> Also consider SwingWorker<T,V>.

That's an excellent point, I completely spaced on the GUI part of his 
question.  If GUI = Swing, then SwingWorker is an excellent solution to 
many problems.

Also, SwingWorkers can be put in executors, and since it returns a 
Future, there's a convenient Future#cancel() method to kill the thing 
(which does use Thread#interrupt as I suggested earlier).

[toc] | [prev] | [standalone]

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

csiph-web