Editing Event dispatching thread (section)

== Message loop for serializing GUI accesses ==

A software application normally consists of multiple threads and a single GIT data structure. This means GIT is a shared data structure and some synchronization is needed to ensure that only one thread accesses it at a time. Though [[Abstract Window Toolkit|AWT]] and [[Swing (Java)|Swing]] expose the ([[Thread safety|thread unsafe]]) methods to create and access the GUI components and these methods are visible to all application threads, likewise in other GUI frameworks, only a single, Event Dispatching thread has the right to execute these methods.<ref>{{cite web
| url=http://download.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html
| title=The Event Dispatch Thread
| publisher=[[Sun Microsystems]]
| accessdate=2011-10-02}}</ref><ref>{{cite web
| url=http://weblogs.java.net/blog/alexfromsun/archive/2005/11/debugging_swing_1.html
| title=Debugging Swing - is it really difficult?
| publisher=Alexander Potochkin
| accessdate=2011-10-02
| archive-url=https://web.archive.org/web/20110805132240/http://weblogs.java.net/blog/alexfromsun/archive/2005/11/debugging_swing_1.html
| archive-date=2011-08-05
| url-status=dead
}}</ref><ref>{{cite web
| url=http://download.oracle.com/javase/tutorial/uiswing/concurrency/initial.html
| title=Initial Threads
| publisher=[[Sun Microsystems]]
| accessdate=2011-10-02}}</ref>
Since programmers often miss this requirement, third-party [[Pluggable look and feel|Look and Feel]]s, like [http://java.net/projects/substance/ Substance] go as far as to refuse to instantiate any Swing component when not running within the Event Dispatch Thread,<ref>{{Cite web|url=http://www.pushing-pixels.org/?p=368|title=Stricter checks on EDT violations in Substance · Pushing Pixels}}</ref> to prevent such a coding mistake. Access to the GUI is serialized and other threads may submit some code to be executed in the EDT through a '''EDT message queue'''.

That is, likewise in other GUI frameworks, the Event Dispatching Thread spends its life pumping messages: it maintains a message queue of actions to be performed over GUI. These requests are submitted to the queue by system and any application thread. EDT consumes them one after another and responds by updating the GUI components. The messages may be well-known actions or involve callbacks, the references to user-methods that must be executed by means of EDT.

The important requirement imposed on all messages is that they must be executed quickly for the GUI to stay responsive. Otherwise, the message loop is blocked and GUI freezing is experienced.