> I'm just delving into the details of how Swing is implemented at > the moment, can't say I agree with half of the "design" decisions > myself. Swing isn't thread safe, although AWT is to my knowledge,
Actually, AWT isn't thread-safe either. Documentation about the fact seems pretty hard to find. From what I can gather, in Java 1.1, AWT claimed to be thread-safe, but there were problems with races and deadlocks, therefore in Java 1.2 and above AWT doesn't claim to be thread-safe. AWT does seem to mostly work if you call it from multiple threads. Some discussion here: http://www.elharo.com/blog/software-development/java/2006/11/10/awt-on-the-event-dispatch-thread/ A brief official reference here: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/applet-compatibility.html Also here: http://web.archive.org/web/20060816013814/http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html There's some more info here about why multi-threaded GUI toolkits aren't such a good idea: http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html Restricting GUI objects to only work from one thread is done so that they don't need to use locking, which makes them faster and less prone to bugs. Lots of GUI toolkits do this, eg: Win32, .NET, SWT. Allowing objects to be accessed from multiple threads makes things slightly easier for clients, but isn't really going to improve performance. Swing does have some annoying aspects of its design (its fake platform UI isn't all that convincing), but I don't think that the single-threaded access model is that bad a thing. -- Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
