What is Event-Dispatching Thread (EDT) in graphical interfaces?
When you are 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 EDT. I know there is an explanation in documentation), but I did not find good and complete explanations in Portuguese.
From this I question: What is EDT and how it does it work while running a graphical interface built using swing / AWT?
1 answers
TL; DR
Is the only thread that can directly manipulate the GUI to avoid concurrency 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 reading an article quoted in the answer to the question that @ Marconi left in the comment I did not know why EDT is the way it is.
If you really want to understand that, make an effort and read:
In short: developing a multithreading GUI framework, where multiple threads can manipulate the screen components, 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 locks in the right place.
However, screens have a nature that makes let this not be so simple: she accepts opposing competing events.
- the program changes the screen and the change is propagated from the highest level components in the hierarchy to the lowest level. For example: from the window, then to the panel, and then to the button.
- user-generated events range from the lowest level components of the hierarchy to the highest level. For example: from the button, to the panel and from the panel to the frame.
All of this causes locks to not work well, generating deadlocks and glitches frequently.
The author says that a lot of efforts were put in at the time when AWT was multithreading and they reached a kind of dead end. The solution was to do what virtually every other GUI framework did: switch to an EDT model.
He still argues that there are multithreading GUI implementations, but they only work well if people that develop the GUI are the same as that develop the framework, as this requires specific and detailed knowledge of the model. However, in a general purpose framework made for large-scale use, this would never work well.
Therefore, in the model 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 some change, they they should fire an event for the AWT thread.
One way 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 EDT blocks the entire program.