[Lazarus] GTK2 threading

[Anton Kavalenka]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20130125/a62e65a2/attachment-0003.html>