Print

Print


On Feb 13, 2008, at 3:41 AM, Siamak Sarmady wrote:

> Hello,
>
> In one of my programs I am just using the Display component of Mason.
>
> The problem is that when I close Display window, program continues to
> run in Background. What else should I do to terminate the entire
> program? (Is it the state object which remains in memory?)

This is a question with a very complex answer, and it's not easy to  
answer given the hack that you're doing here.  So some background.   
When you press "play" on the Console, here's what it does in short:

1. Calls start() on the GUIState (which in turn calls start() on the  
underlying SimState)
2. Spawns a thread (the "play thread") which:
	2a. Blocks waiting for all Swing Events to have completed (using  
SwingUtilities.invokeAndWait)
	2b.  Loops:
		2b.i. calls simulation.step() to step the simulation once.  This  
automatically synchronizes on the schedule until the step is completed.
		2b.ii. Blocks until all Swing Events have completed

When we try (from the Swing event thread) to repaint the window or  
inspect an object in the window or modify a feature of an object, we  
first synchronize on the underlying Schedule.  This causes us to  
block until the playThread's call of simulation.step() has completed,  
so we don't modify or read bad stuff on the model.

When you call "stop" on the Console we:

1. Interrupt the play thread (since we were called via a java event  
-- mouse click on stop button -- we know we have control and the  
underlying thread is blocking waiting for our Swing Event to complete.

2. Kill the play thread

3. Call finish() on the GUIState


[Keep in mind that you should call init() on the GUIState and also  
quit() on it when you first create it and later destroy it at the end  
of your application.]

The important item to note here is that MASON's GUI facilities are  
designed to hand off a baton and forth between an underlying thread  
(called the "play thread") and Swing.  Whoever has the baton is  
allowed to read/write the model and the schedule, otherwise they have  
to wait.  Waiting for and acquiring the baton is easy: just  
synchronize on the Schedule.

It looks like you are deviating from this model in two ways:

1. You're not handing off the baton.  This could result in race  
conditions you don't want to see.
2. Your model thread (the equivalent of the "play thread" above) is  
the underlying main() thread perhaps?  It's not made clear.   
Ordinarily in Java GUI applications, the main thread just sets things  
up and dies.

The easiest way to handle this is to NOT call start(), but rather let  
the console handle it for you.  Just call console.pressPlay() to  
start the simulation, and console.pressStop() to stop the  
simulation.  You really ought to do these from the GUI thread, not  
the main thread.  If you're not in the GUI thread, you can still do  
this by creating a small Runnable, whose sole function in life is to  
call console.pressPlay(), and adding him to SwingUtilities with a  
SwingUtilities.invokeAndWait(...).  Likewise for console.pressStop().

When the Display2D's window is disposed, by default it calls  
Display2D.quit() first.  But note that in Java by default when you  
click on a close box in a window, it doesn't dispose the window.  It  
just hides it.  That's what MASON is relying on -- it's just hiding  
the window.  You can change the behavior of closing the window to  
actually dispose the window (and thus call quit()), look at JFrame's  
documentation.  Basically, let Display2D create its window with  
createFrame(), and then change that frame's close-box behavior.

If you do this, you will also want to hook into JFrame's quit()  
method to quit your program when the window is closed.  The quick and  
dirty, ugly way to do this is to just override the quit() method in  
Display2D to call System.exit(0).  That will kill everything  
immediately and quit your application.  A better approach would be to  
call console.doClose(), which will cleanly shut down and dispose  
everything.

Good luck!  Beware that multithreading coding in Swing is  
nontrivial!  :-)

Sean