<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 25.01.2013 14:51, Mattias Gaertner
wrote:<br>
</div>
<blockquote
cite="mid:387702159.81141.1359114687183.JavaMail.open-xchange@comcenter.netcologne.de"
type="cite">
<pre wrap="">
Anton Kavalenka <a class="moz-txt-link-rfc2396E" href="mailto:anton.k@tut.by"><anton.k@tut.by></a> hat am 25. Januar 2013 um 12:21 geschrieben:
</pre>
<blockquote type="cite">
<pre wrap="">On 23.01.2013 11:44, Michael Schnell wrote:
> > On 01/22/2013 06:52 PM, Anton Kavalenka wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
> > >
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">
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!
</pre>
</blockquote>
<pre wrap="">
The problem is in LCL implementation itself, not in event queuing.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">
Can you give me the bug report link?
</pre>
<br>
</blockquote>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Was reported in bug-tracker<br>
<a href="http://bugs.freepascal.org/view.php?id=24120">http://bugs.freepascal.org/view.php?id=24120</a><br>
<br>
with best regards,<br>
Anton<br>
<br>
</body>
</html>