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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
