Well, typically, GUI handler functions do not run by default asynchronously. For example, on Win32, you have an infinite loop in main() fetching and dispatching events. The dispatching happens in the same thread. Of course, for small and simple programs that might be OK, but for anything slightly more complicated, that's bad because the GUI seems frozen while a handler is executing. To overcome this, you have to manually create other threads. Typically, the main thread remains for the GUI events and re-drawing, while the other threads do "the job", whatever that might be. And, of course, you have to use synchronization explicitly with locks etc. in order to avoid data corruption.
High level UI frameworks might make all of that much easier by hiding the event loop, synchronization, the creation of threads etc. but, under the hood, it's the same thing. There are a ton of approaches to this problem, including the modern async/await constructs, but in no case you can completely forget that there are multiple threads of execution and one of them should be dedicated to the GUI.
_________________ Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck
|