On 23.01.2013 11:44, Michael Schnell wrote:
On 01/22/2013 06:52 PM, Anton Kavalenka wrote:
But GTK Widgetset uses pure Xlib calls for determining keyboard states.
Xlib thread-safety is not initialized in GTK2 widgetset.
AFAIK: As the GUI and Event-queue related LCL classes (i.e.
TApplication) are not thread save themselves (e.g. using global
variables). It does not make sense to attach to the System's Widget
set in a thread safe way.
To allow for multiple GUI threads a major update of the appropriate
LCL functions would be necessary, so that multiple threads can create
their own dedicated TApplication instances.
-Michael
Dear Michael!
The problem is in LCL implementation itself, not in event queuing.
Real life example:
Off-screen composing is made into TBitmap.
Screen update is made via Synchronize() call or sending a message to the
control (it does not matter).
This approach works both in Win32/64 and Carbon.
But in LCL-GTK:
Getting and setting bitmap data invoke GTK and Xlib calls.
If it were pure GTK - all would be OK.
GTK is thread-safe and uses mutexes internally.
X is also thread-safe (as soon XInitThreads called).
But currently LCL-GTK is a mix of Xlib and GTK calls, and threading for
XLib is NOT initialized.
The described example works until i click the form.
This beaks X-message flow.
GTK does not block Xlib and vice versa.
As I have already written, I'll try to provide the "example" of problem,
which works in Win32,Carbon but fails in GTK.
regards,
Anton
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
