More robust threading

We’ve been working on a project that utilizes diagnostic tests on equipment that can take on the order of an hour. These tests have python scripts associated with them which are fired off in separate threads using the invokeAsynchronous function. Later we may add threads containing infinite loops. Sometimes we need to kill threads prematurely. It’d be nice if invokeAsynchronous returned a thread ID that could later be used to kill the thread.

A workaround we’ve come up with (but not implemented yet) is to have a global flag area (properties of the root container, perhaps) that the threads poll to see if they should kill themselves. Something like this is necessary for the threads with while(1) loops. Semaphore/mutex-like components would be handy, too.

We’d also like the ability to have a thread change GUI indicators. From what I understand, invokeLater() won’t accomplish what we need, as the thread never actually finishes. This question may be more suited for the design help forum, but I’ll tack it here because the preceding paragraphs explain what we’re trying to accomplish. Could you elaborate on the specifics of what I can’t do from a thread? It says not to play with the GUI…if I can guarantee that my thread is the only thing that can adjust, say, the color of an indicator, and likewise guarantee that only one such thread will be in existence, can I adjust the property? If not, do these critical regions apply to non-GUI properties - for example, the flags I mentioned in the previous paragraph? If I can adjust those, can I set up a dynamic property that is safe to write to from the thread, then bind a GUI component’s properties to that component? I suppose if none of those work, mysql is thread safe, so I could write to a table from the thread and bind the property to a query, but this seems like far more than is necessary.

Thanks guys.

You should have all of the theading ability you need to accomplish what you’re doing.

First of all, you’re correct that you shouldn’t directly affect the GUI from an invokeAsynch thread (nice job actually reading the manual!), but you’ve misunderstood the invokeLater command. That command will execute even when called from a non-terminating thread, because it invokes later on the GUI thread. This means that it is a safe way to communicate back from a long-running thread to the EDT (Event Dispatch Thread, a.k.a. the GUI thread).

Second, you can safely use Client SQLTags or DB SQLTags for inter-thread communication - both for the thread to feed status back to a screen and to communicate to the thread to stop or alter its state.

Lastly, although I’m not sure you need them, you’ve got access to all of the semaphore and mutex stuff you could ever wish for by hooking into the Java system. Check out the java.util.concurrent package over at the Java API Docs

Awesome. Thanks a bunch

One thing we could really use is a “kill thread” function. My boss asked for some added functionality since my last post, and the polling method I described earlier won’t cut it anymore.


Again, this is something that you can already do.

If you start a new thread with invokeAsynchronous, the thread will die when your function returns. This means that you’re probably doing something in a loop if your thread is staying alive. So to kill the thread - flip some flag that makes the loop stop. i.e.:

global canceled
while not canceled:
  ... do something ...

This thread is one sequential process, not a repeated loop, but it can take a long time to run nonetheless (it’s IO heavy and has to wait for equipment to react), and we’d like the ability to abandon early if some more pressing issue came up a half hour into the process. To use the method you describe, we would have to throw checks in throughout the process and in any of the IO library functions that take non-trivial amounts of time…this can be accomplished, but is obviously less-than-ideal.

What would be very nice is a function like this, where we don’t have to program the kill thread polling logic throughout every threaded function we write.

Ok point taken.
Remember that this is a Java environment, which is not a POSIX threading system. Your best bet would be to create a thread yourself, and then you can later interrupt it.

thread.interrupt() will throw an InterruptedException from any blocked IO or sleeping, but won’t actually affect it if it is actively running (number crunching or something). For that you can manually check the interrupted status. You may be tempted to call thread.stop(). Don’t. Read about Java threading here: … hread.html

[code]from java.lang import Runnable,Thread
class MyProcess(Runnable):

def run(self):
from java.lang import Thread

  ... Do my long-running thing...

  # Optionally check for interrupted status
  if Thread.interrupted():

  ... do more long-running stuff ...

thread= Thread(MyProcess())

… sometime later …


Hope this helps,

:prayer: Yes, this is quite helpful. You’ll have to excuse me, I come from a C and UNIX background, so my Java experience is a bit limited…

Could you clarify one point for me? You said the interrupt method will not do anything if the thread is running, but it’ll throw an exception if the thread is blocked. Would something like this work without throwing in the manual checks, or would firing the interrupt while the thread is running guarantee that I would need to do the manual check inside the thread?

def kill( threadToKill ):
   while( threadToKill.isAlive() ):
      time.sleep( 1 )

Or, alternatively, since a sleeping thread will be interrupted, something like this:

def kill( threadToKill ):
   threadToKill.sleep( ABSURDLY_LONG_TIME )
   while ( threadToKill.getState() == thread.state.RUNNABLE ): #ensure thread has gone to sleep

Actually no, let me clarify. I might mave made a mountain out of a molehill with that caveat.

You should be able to simply interrupt your thread and forget about it. it doesn’t “do nothing” if the thread is actively executing code - but the thread will continue running until it tries to do something that it can’t if it has been interrupted, like some IO or waiting (sleeping).

If your thread is in a hard infinite loop, interrupting won’t do anything, but as long as it is acting normally (some execution, some io, some sleeping, rinse, repeat), interrupt will kill it, just (potentially) not immediately.

Thanks for the clarification. This helps a lot.