A proper way to close Frame in multi-threaded environment

Discussion in 'Java' started by nukleus, Jan 18, 2007.

  1. nukleus

    nukleus Guest

    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.
     
    nukleus, Jan 18, 2007
    #1
    1. Advertising

  2. 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.
     
    Andrew Thompson, Jan 18, 2007
    #2
    1. Advertising

  3. nukleus

    Tom Hawtin Guest

    nukleus wrote:
    > 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
     
    Tom Hawtin, Jan 18, 2007
    #3
  4. nukleus

    nukleus Guest

    In article <45af7c7f$0$8735$>, Tom Hawtin
    <> wrote:
    >nukleus wrote:
    >> 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,


    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.

    >Tom Hawtin
     
    nukleus, Jan 19, 2007
    #4
  5. nukleus

    Chris Uppal Guest

    nukleus wrote:

    > 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
     
    Chris Uppal, Jan 19, 2007
    #5
  6. nukleus

    Tom Hawtin Guest

    nukleus wrote:
    >
    > 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
     
    Tom Hawtin, Jan 19, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ian douglas
    Replies:
    2
    Views:
    1,026
    Randy Howard
    Jul 30, 2004
  2. Replies:
    16
    Views:
    6,167
  3. mk
    Replies:
    1
    Views:
    335
    Jonathan Hartley
    Dec 30, 2009
  4. Iñaki Baz Castillo
    Replies:
    7
    Views:
    938
    Iñaki Baz Castillo
    Jan 12, 2010
  5. shooshx
    Replies:
    2
    Views:
    345
Loading...

Share This Page