What is Event-Dispatching Thread (EDT) in graphical interfaces?

Question

When learning to build graphical interfaces with swing/AWT, you hear a lot about the Event-Dispatching Thread (or EDT). Although I already have a certain coexistence with swing, I confess that I do not understand well what comes to be the EDT. I know there’s an explanation in documentation (in English), but I did not find good and complete explanations in Portuguese.

From this I question: What is the EDT and how it works during the execution of a graphical interface built using swing/AWT?

Answer 1

TL;DR

It is the only thread that can directly manipulate the graphical interface to avoid competition problems. It sits in a loop waiting for events coming from the screen (clicks, keys, etc.) or directly from the program and applies all changes sequentially.

Motivation

I confess that until I read an article quoted in the answer to the question that @Marconi left in the comment I didn’t know why EDT is the way it is.

If you really want to understand this, make an effort and read:

Multithreaded toolkits: A failed Dream?

In short: develop a multithreading GUI framework, where several threads can handle the components of the screen, does not work in practice.

The author argues that at first creating a multithreading graphical interface seems almost trivial, just a matter of putting the Ocks in the right place.

However, screens have a nature that makes it not so simple: it accepts opposite competing events.

1. The program changes the screen and the change is propagated from the highest-level components in the hierarchy to the lowest-level components. For example: From the window, then to the panel and then to the button.
2. User-generated events range from the lowest-level components of the hierarchy to the highest-level ones. For example: from button to panel and from panel to frame.

All this makes the Ocks not work well, generating deadlocks and glitches frequently.

The author says that many efforts were put in at the time when the AWT was multithreading and they arrived at a kind of dead end. The solution was to do what virtually all other GUI frameworks did: switch to an EDT model.

He further argues that there are multithreading GUI implementations, but they only work well if the people who develop the GUI are the same people who develop the framework, as this requires specific and detailed knowledge of the model. However, in a general-purpose framework designed for large-scale use, it would never work well.

Therefore, in the template using EDT, changes to the GUI are all made using a single thread (single threaded) managed by the framework and when the other threads (such as the main thread of the program) want to make any changes, they must trigger an event to the AWT thread.

One of the ways to do this is by using invokeLater, but within event handlers (listeners) this is not necessary because they run within the AWT thread, which also implies that any time-consuming processing within the EDT blocks the entire program.