-----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. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtYSrCojCW6H2z/QRAsS4AKDhPGi/T2sSzI9pT1yhymJGPuSAJwCdHcji JX3f7o9LmnlZe0L4IOLWtQk= =f8Tj -----END PGP SIGNATURE----- _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
