-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 26 May 2004 19:44, Thomas Fitzsimmons wrote:
Another problem I noticed -- as soon as a toolkit is instantiated, the code doesn't exit anymore, presumably because some thread is hanging on -- even something as simple as getDefaultToolkit().getScreenSize() needs a Ctrl+C. It doesn't seem to be a JVM problem (same on Jam, Sable and gij) so must be something in the shared gcj/classpath code for the AWT (either in the main code or in the peers).
Yes, this is still a problem. I haven't figured out yet what should be the exit criteria for a GUI app.
As Andrew said; when the last non-daemon thread dies;
the Sun JVM has a really nice feature to throw a stacktrace of all threads using one command (the EOF char; ctrl-\) if not present; please place that
on a feature request list somwhere :)
Anyway; there is a "Suspend Checker Thread" in that stacktrace that displays a nice idea. (give me an email if you want an example traces-output)
I'm wondering if you guys thought about the concept of application-contexts. The seperation of AWT applications in one JVM. Using this concept (which is implemented in a sun.awt package) you can create multiple AWT-Event threads and multiple totally seperate component-hierarchies which allows (for intstance) to have multiple L&Fs installed.
The java.awt.Frame.getFrames() uses that application-context, for instance.
The implementation on Suns side has some bugs making it unusable; but the idea is certainly _very_ appealing to me.
Hi,
I have a small test case that hangs on SableVM but finishes on Sun's VM's, and apparently kaffe and gij.
SableVM Java stack traces (with CTRL-\) show that one thread gets stuck in java.awt.EventDispatchThread.run()
(VMObject.java:-1) java/lang/VMObject.wait n (Object.java:445) java/lang/Object.wait (EventQueue.java:98) java/awt/EventQueue.getNextEvent (EventDispatchThread.java:64) java/awt/EventDispatchThread.run (VMThread.java:116) java/lang/VMThread.callRun (Thread.java:386) java/lang/Thread.callRun (VirtualMachine.java:117) java/lang/VirtualMachine.runThread
while the other is stuck in DestroyJavaVM() waiting for all non-daemon threads to die.
Can anyone comment on the 3 conditions listed in the implementation-dependent section of:
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/doc-files/AWTThreadIssues.html
and on if there's yet treatment of them in Classpath, in the java-gui branch of gcj, or even plans for treatment? Is Sun's way the right way? I guess if gij works then something must have been done ...
Cheers, Chris
import java.awt.Frame;
public class AwtUtils2 {
public static void main(String[] args) {
MyThread t = new MyThread();
t.run();
}
}
class MyThread extends Thread {
public void run() {
try {
Frame f = new Frame();
System.out.println("hello");
f.dispose();
} catch (Throwable t) {
}
}
}
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
