De Icaza: Callbacks as our Generations' Go To Statement
Posted Aug 20, 2013 19:26 UTC (Tue) by magnus
In reply to: De Icaza: Callbacks as our Generations' Go To Statement
Parent article: De Icaza: Callbacks as our Generations' Go To Statement
I would extending the queue idea by saying that all callbacks/slots from GUI should run in different threads like you are saying. All GUI updates operations should go through the global queue.
Hmm I did some more thinking on this. :)
While you don't want processing unrelated to the GUI to block the GUI thread, at the same time you DO want the GUI to be blocked while you modify the UI state because that simplifies the processing and avoids a lot of races. The toolkit can guarantee for example if you close a window inside a callback that you can not get more events to that window that were enqueued between the callback was called and the delete call.
So whatever method you use, you have some parts of the application UI logic that should be synchronous to the GUI (GUI is blocked and code must be non-blocking) and some that are asynchronous (GUI is not blocked and code may block). Neither lightweight threads or using event queues for everything will solve that problem by itself...
to post comments)