Threads

[Michael Finney]

Threads. I feel they should go away in a clean manner.
Ok. Well, I am curious as to how to make a Frame go away gracefully. (not a setVisible thing)
Often I see examples use System.exit(0). However, System.exit(int) makes everything go away abruptly. I'd like all the threads to go away gracefully.
Perhaps I would understand better if I knew what thread it is the Frame is using to capture the GUI input events. The Frame must be looping, capturing the events, and handling them.
Thoughts?
Thanks
Michael

[This message has been edited by Michael Finney (edited July 10, 1999).]

[Michael Finney]

I tried setVisibile(false) and dispose() in the WindowListener.WindowClosing event handler.
Nope.

[Matt Midcap]

I have the same symptoms with one of mine, still looking....

[Pawel Veselov]

About GUI events - there is a special thread, that generate it - you can see it in this trace. So Frame does not listen for events. Event thread catches all events (via this motif.InputThread, I believe) and then distribute them among components.



Debugging the applcation that does setVisible(false) and dispose() on only existing frame shows that this threads listed below are always present after any window was shown on screen. I believe, that application should have a possibility to kill all it's frames and then open a lot of another frames, so we don't want JVM to die after all frames were disposed.



So, if you do want to control all of your frames and die when all frames are disposed, you call System.exit(int).
<pre>
jdb[vps@druid]~/jprogs$ jdb Popup
Initializing jdb...
0xee2c7fc0:class(Popup)
> stop in Popup.<init>
Breakpoint set in Popup.<init>
> run
run Popup
running ...
main[1]
Breakpoint hit: Popup.<init> (Popup:9)
main[1] threads
Group Popup.main:
1. (sun.tools.debug.MainThread)0xee2c5310 main at breakpoint
main[1] cont
main[1] threads
Group Popup.main:
1. (java.awt.EventDispatchThread)0xee2c3f80 AWT-EventQueue-0 cond. waiting
2. (sun.awt.motif.InputThread)0xee2c3f98 AWT-Input running
3. (java.lang.Thread)0xee2c3fb8 AWT-Motif cond. waiting
4. (sun.awt.ScreenUpdater)0xee2c8eb0 Screen Updater cond. waiting
main[1] quit
[vps@druid]~/jprogs$
</pre>

------------------
With best of best regards, Pawel S. Veselov ( aka Black Angel )

[Michael Finney]

Are assignments in Java atomic (primitive or reference)?
In other words, are assignments thread safe?
Can one thread interrupt another thread in the middle of an assignment and mess with the same variable?
Can you show me in the Java Spec? http://java.sun.com/docs/books/jls/html/index.html http://java.sun.com/docs/books/jls/clarify.html http://java.sun.com/docs/books/jls/html/1.1Update.html
Thanks.
[This message has been edited by Michael Finney (edited January 10, 2000).]

[Thandapani Saravanan]

I think the assignment of double or long variables is non-atomic and needs programmer attention. These assignments need to be within a synchronized block.
Actually, i have not tried this in programs. JLS 17.4 gives more detail.

[paul wheaton]

Thandapani is right. but, char, int and references are not interrupted. But double and long can be interrupted.