Windowing system callback question

[Robert]

Hi!
I'm not really experienced in this topic, so maybe this will be a wrong question.
So: An application registers its main window, draws it, etc.
Then when user clicks on a button OS calls the application's GUI handler. How could it be a safe call,
if it's in the same address space with the app's main process (so it's able to modify app's data asynchronously)?

Thanks for the answer(s)

[vvaltchev]

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.

[Robert]

Thanks for the answer. I was afraid there is no simple solution for this problem...

[OSwhatever]

Most of the callbacks aren't called from the kernel and the callbacks are implemented in userspace. Many times on Linux systems, the thread will go into the "select" system call and wait the for some event, then when it returns to the user space implementation will invoke the appropriate callback. Same should go for Windows that goes into WaitOfSingleObject or WaitForMultipleObjects. So in practice you just need one thread for your entire main loop that handles all the events.

When it comes to GUI design, most of the are single threaded or at least the update is single threaded. I think this is a good approach because making all GUI objects work in a multithreaded environment where several threads poke around with them would be difficult and open up for tons of bugs.

[alexfru]

Events can be buffered/queued by either the OS or the app until the app can safely consume them.