[Lazarus] GTK2 threading

[Anton Kavalenka]

On 25.01.2013 14:51, Mattias Gaertner wrote:
> Anton Kavalenka <anton.k at tut.by> hat am 25. Januar 2013 um 12:21 geschrieben:
>
>> 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.
> I guess, Michael meant, that the LCL only accesses the widgetset via the main
> thread and therefore should not need any thread control.
> But the LCL does not check if it is called by another thread. So you can shoot
> yourself in the foot by doing so.
>
>
>>   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.
> Can you give me the bug report link?
>
>
>>   As I have already written, I'll try to provide the "example" of problem,
>>   which works in Win32,Carbon but fails in GTK.
>
> Mattias
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

As I have already mentioned XLib does not know that GTK is blocing 
message flow.

Searching into GTK2 interface brings at least the following files use Xlib
gtk2extrah.inc
gtk2int.pas
gtk2proc.inc
gtk2proc.pp
gtk2wsextctrls.pp
gtk2wsforms.pp

GTK2 pretends to be complete platform-agnostic interface.
Why Xlib and X is needed in GTK2 widgeset at all?

g_thread_init(nil);
- this initializes internal GTK2 mutexes, XLib does not know about them.

regards,
Anton