A proper way to close Frame in multi-threaded environment

[nukleus]

I have some old java code that is having a problem when closing frames.
It is all AWT code, no javax.
The main frame class opens another frame to do actual work,
which creates a new thread to do actual work and the main object
(for this frame) behaves like a supervisor of sorts. No matter what
happens to the worker thread, you still have control of gui and can
terminate things if network connection hangs, unexpected data
arrives, etc.

The problem is this. The worker thread needs to be terminated,
which is easy enough, when user hits abort key, the event handler
sets some variable, which is tested in the main run() loop.

Then, when the main run loop terminates, it calls the Terminator()
that does dispose(). That seems to be working fine and things
close logically correct. Even if user hits Abort button in the
middle of a lengty network operation, we do not destroy the
worker frame until its thread terminates. Otherwise, after worker
frame is closed, we may still be getting log messages in the log
text area of the main frame after worker frame was destroyed,
which looks weird, we aborted the process, but still keep getting
the log messages sent by the worker thread.

The question is: is is the right approach?
The old code used to simply kill the worker thread,
which would crash the program in some situations.

Secondly, the way it is done is to create a worker frame object
when the main frame goes thru initialization phases.
The worker frame never really gets destroyed, even after we
Abort some operation. It simply gets hidden. Since worker frame
creates a separate thread to run, we have a non-blocking
dialog of worker frame that can remain open simultaneously
with the main frame and both of them do not interfere with each other.
That means, we can load the new configuration parameters
for the program and keep the worker frame open and it will
correctly display all the new parameters from a different configuration set.
The same case is with other frames performing different tasks.
Their guis are properly updated with new config info.

The drawback: since worker frame loads various archive files
of very large size and, not being actually destroyed, causes consumption
of large amount of memory, held by various vectors and buffers.
So, effectively, the garbage collection does not happen and we have to
manually free the vectors, buffers, etc. that are not needed at the moment.

If worker frame was destroyed, the whole thing with memory management
would become much simplier as all the objects, buffers and vectors
would get deallocated with next invocation of garbage collector.

So, the question is eternally the same: what to do?
On one hand, we would like this luxury of being able to see
everything simultaneously in various frames, and, on the other hand,
as long as they exist, they can potentially tie up large amounts of memory.

Does anyone have an opinion on this?

Thanks.

 

[Andrew Thompson]

nukleus wrote:

(big snip)

(GUI stuff)

..they can potentially tie up large amounts of memory.

Does anyone have an opinion on this?

(phew) That was a long question.

My (short) answer is "premature optimisation".

Slightly longer. I have never been swayed by
arguments that you must free every bit of memory
used by GUI elements. If an application is suffering
OutOfMemoryError's, it is probably due to memory
*leaks*, and a few, a few hundred, or even a few
thousand GUI components is not going to make
much difference (except the VM will hit the OOM
*slightly* sooner - so it might actually *help* the
debugging!).

Andrew T.

 

[Tom Hawtin]

I have some old java code that is having a problem when closing frames.
It is all AWT code, no javax.

Even so, AWT isn't really thread-safe. Almost certainly application code
using AWT will be highly thread-unsafe. Therefore, I suggest using
java.awt.EventQueue.invokeLater as with Swing.

I don't entirely follow your post, but I would suggest keeping classes
small to make the code understandable. In particular, any class that
extends Frame, for instance, is going to be huge (in total).

Tom Hawtin

 

[nukleus]

Even so, AWT isn't really thread-safe. Almost certainly application code
using AWT will be highly thread-unsafe. Therefore, I suggest using
java.awt.EventQueue.invokeLater as with Swing.

I don't entirely follow your post,

Well, the whole thing is simple. How do you close the frame properly?
Is it enough to just call dispose()?
And what happens to a worker thread that frame might have created?

but I would suggest keeping classes
small to make the code understandable. In particular, any class that
extends Frame, for instance, is going to be huge (in total).

That is exactly what i am wrestling with since the beginning.
The original code had just a few classes and they were huge
if not humongous. Everything was lumped in one class,
including gui, working routines, utility functions and you name it.
Especiall the main frame class as it was used to keep track
of everything under the sun.

Now, when i started rewriting the frame classes, i did it in such
a way that the gui related code is completely separate from the
class using a particular frame. So, the class framework can be
generated by gui designer and not touched by hand.
Then, a particular gui frame class is extended with code
related to that specific gui frame.

So far, seems to be working just fine. GUI designer generates
all basic code including the event handling.

Thanks.

 

[Chris Uppal]

Well, the whole thing is simple. How do you close the frame properly?
Is it enough to just call dispose()?

As far as I know, yes.

And what happens to a worker thread that frame might have created?

Nothing. If you want the thread to die at the same time (more or less) as the
frame then you'll need explicit code somewhere to /tell/ it to die.

-- chris

 

[Tom Hawtin]

Well, the whole thing is simple. How do you close the frame properly?
Is it enough to just call dispose()?

Dispose will close the frame and release any associated GUI resources
(including the non-Daemon AWT threads if there are no other windows
undisposed).

And what happens to a worker thread that frame might have created?

java.awt.Frame has no worker threads. Make you own threads exit nicely
when instructed.

Tom Hawtin