In order to prevent my programs from freezing up while running long calculations, I generally run the calculations on separate threads. In Java, this process can be accomplished by separating the GUI from processing. In the code below, a thread for an instance of MyProcessing would be invoked using start(): e.g. “(new MyProcessing()).start();” would run indefinitely until T is made null. T can be made null by calling stop() or by directly making T null. Often when the GUI is closing, I call stop() on all the threads associated with that GUI regardless of whether or not I know that any are active.
/* Here is the processing */
public class MyProcessing implements Runnable {
Thread T = null;
public MyProcessing() {
}
public void start() {
if(T == null) {
T = new Thread(this);
T.start();
}
}
public void stop() {
T = null;
}
public void pause(int n) {
try {
/* I add pauses to prevent overheating */
T.sleep(n);
}
catch(Throwable r) {
}
}
public void run() {
while(T != null) {
System.out.println(“Hello World Forever!”);
/* Do all of this stuff forever – until T is made null */
pause(10);
}
}
}
The infinite loop is useful when there is something running for an infinite period of time – such as looped clip. I wrote in the program below in 1998 – in Java. It can show a series of frames made up of vector data; and it can run this series as a loop. Usually there is a pause between frames and then a fast render and refresh – creating what “appears” to be movement. These days I use the rendering environment mostly for output to show the results of complex calculations. But yes the output can be animated.
It is more common not to run infinite loops, of course. The run() method might be something like the code below . . .
public void run() {
/* Notice the “T != null” among the conditions */
for(int i = 0; T != null && i < 100000; i++) {
/* Do this lengthy operation */
}
/* Just to be perfectly clear */
stop();
}
Below is a GUI for a system that often takes several days to complete a job. It can run many jobs. When I close the GUI down and restart the program later, it can continue “near” where it left off. The GUI never freezes on the screen. The good part is, I can eat and sleep while the program is running without worrying about overheated equipment. I can continue running the program that generated data for this system without interfering with the processing environment.
As shown below, the processing environment (the “Crosswave Server”) is very much detached from the GUI. I can actually work on the software for the GUI – and the other major components – while leaving the server system to run.
In order to be notified when an operation is complete, I suppose the GUI can be made to check for completed output. Typically I pass the current instance of the GUI to processing; then I cause the processing program to invoke a particular method on the GUI when calculations are over. I’m not exactly sure if that makes much sense. Write to me for further details. Those that deal with lots of data who also write their own software should learn to make effective use of separate threads and methods of parallel and distributed processing.
