[Lazarus] Even more radical suggestion regarding Event Queues

[michael.vancanneyt at wisa.be]

On Thu, 20 Jan 2011, Michael Schnell wrote:

> After some more thinking about the issue:
>
> Obviously doing Event Queues with the current Linux based Widget Types is not 
> easy to do (in the way it is done right now). In some revisions PostMessage 
> does not work at all, in some revisions TApplication.QueueAsyncCall does not 
> work as expected, in some revisions TThread.Synchronize does not work as 
> expected (While TThread.Queue is not implemented at all).
>
> As far as I understand, (e.g.) the gtk (2) Widget Set is used by a "loop" 
> (repeated call or callback) that alternately runs the Widget Set code and the 
> application program code, while the widget set code (additionally) performs 
> callbacks into the application program code when a GUI event is fired by the 
> user's interaction.
>
> Now, at some point the code (GUI Thread) needs to go to sleep if nothing is 
> to be done. It seems like the Widget Set is done in a way that it 
> automatically wakes up the GUI Thread when user interaction is detected and 
> thus the appropriate Callback is done and seemingly as a consequence, the 
> "loop"ed code in the application program is executed, too, resulting in 
> execution of all events scheduled up till now.
>
> This results in the problem, that waking up the program whenever an event is 
> to be handled that is not generated by the Widget Set, is not that easy to 
> do. (Especially regarding that doing too much polling will degrade the 
> overall performance.)
>
> With Windows, this problem does not appear, as non-GUI events are scheduled 
> by a PostMessage() or PostThreadMessage() API call, that automatically wake 
> up the target-thread.
>
> So a more radical way of Event handling with Linux could be worth 
> considering.
>
> The Widget Set could be assigned to a dedicated thread, while it's callbacks 
> are transferred to the main thread via the application's message queue (that 
> is implemented anyway) by Application.QueueAsyncCall().
>
> The Pro being:
> - The Main thread is completely independent of the GUI, the sleeping and 
> waking of the main thread can be done with pure Linux means, automatically 
> scheduling the GUI- and the non-GUI- events appropriately, while the GUI 
> thread does it's work undisturbed by that.
> - no necessity to permanently run (poll) the Widget Set loop, reducing the 
> overall CPU time

That's wrong. The thread would then run the widget set loop, since that must
be run in every scenario. And Poll() does not consume any CPU.

I would never use a widget set with the structure you describe. Threading
problems are extremely difficult to debug, doubly so in an event based
system. What's more, X11 is not thread-safe at all.

Michael.