[Lazarus] GTK2 threading
anton.k at tut.by
Fri Jan 25 12:21:00 CET 2013
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lazarus