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.