Re: Working On Classpath

[Chris Pickett]

Thomas Zander wrote:
> -----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) {
        }
    }
}