Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2013-01

GTK2 threading

18 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Anton Kavalenka

Dear Lazarus developers!

I'm examining the problem disturbing me for years.

GTK2 applications provide thread-safety using internal mutexes passed through gdk_thread_init()
And it works.

Pure X-Applcation does so (orders X-messages per-thread) using XInitThreads at early start of application.
And it also works

But GTK Widgetset uses pure Xlib calls for determining keyboard states. Xlib thread-safety is not initialized in GTK2 widgetset.

IMO the problem half-way to resolve - either not use Xlib calls (pure GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable. Or block GTK calls until Xlib call returned.

with best regards,
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130122/9babc062/attachment.html>

Reply by email

zeljko
to Anton Kavalenka
Anton Kavalenka wrote 18 lines
Dear Lazarus developers! I'm examining the problem disturbing me for years. GTK2 applications provide thread-safety using internal mutexes passed through gdk_thread_init() And it works. Pure X-Applcation does so (orders X-messages per-thread) using XInitThreads at early start of application. And it also works But GTK Widgetset uses pure Xlib calls for determining keyboard states. Xlib thread-safety is not initialized in GTK2 widgetset. IMO the problem half-way to resolve - either not use Xlib calls (pure GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable. Or block GTK calls until Xlib call returned.

Feel free to provide patch.

zeljko

Reply by email

Anton Kavalenka
to zeljko
zeljko wrote 22 lines
On Tuesday 22 of January 2013 18:52:31 Anton Kavalenka wrote: > Dear Lazarus developers! > > I'm examining the problem disturbing me for years. > > GTK2 applications provide thread-safety using internal mutexes passed > through gdk_thread_init() > And it works. > > Pure X-Applcation does so (orders X-messages per-thread) using > XInitThreads at early start of application. > And it also works > > But GTK Widgetset uses pure Xlib calls for determining keyboard states. > Xlib thread-safety is not initialized in GTK2 widgetset. > > IMO the problem half-way to resolve - either not use Xlib calls (pure > GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable. > Or block GTK calls until Xlib call returned. Feel free to provide patch. zeljko

I'd like to, but i'm not a great expert in X - so i've subscribed to the list to discuss.

using XinitThreads at start of the program blocks GTK painting. Forms are shown, but no text output.

So - no way to alter XLib internals. The only way - to initialize GTK threading in a way compatibel with X.

regards,
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130122/d6089415/attachment.html>

Reply by email

zeljko
to Anton Kavalenka
Anton Kavalenka wrote 33 lines
On 22.01.2013 20:56, zeljko wrote: > On Tuesday 22 of January 2013 18:52:31 Anton Kavalenka wrote: >> Dear Lazarus developers! >> >> I'm examining the problem disturbing me for years. >> >> GTK2 applications provide thread-safety using internal mutexes passed >> through gdk_thread_init() >> And it works. >> >> Pure X-Applcation does so (orders X-messages per-thread) using >> XInitThreads at early start of application. >> And it also works >> >> But GTK Widgetset uses pure Xlib calls for determining keyboard states. >> Xlib thread-safety is not initialized in GTK2 widgetset. >> >> IMO the problem half-way to resolve - either not use Xlib calls (pure >> GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable. >> Or block GTK calls until Xlib call returned. > > Feel free to provide patch. > > zeljko I'd like to, but i'm not a great expert in X - so i've subscribed to the list to discuss. using XinitThreads at start of the program blocks GTK painting. Forms are shown, but no text output. So - no way to alter XLib internals. The only way - to initialize GTK threading in a way compatibel with X.

So no way to use critical sections while calling xlib directly ? Can you open an issue and attach example ?

z.

Reply by email

Anton Kavalenka
to zeljko
zeljko wrote 37 lines
On Tuesday 22 of January 2013 19:04:43 Anton Kavalenka wrote: > On 22.01.2013 20:56, zeljko wrote: >> On Tuesday 22 of January 2013 18:52:31 Anton Kavalenka wrote: >>> Dear Lazarus developers! >>> >>> I'm examining the problem disturbing me for years. >>> >>> GTK2 applications provide thread-safety using internal mutexes passed >>> through gdk_thread_init() >>> And it works. >>> >>> Pure X-Applcation does so (orders X-messages per-thread) using >>> XInitThreads at early start of application. >>> And it also works >>> >>> But GTK Widgetset uses pure Xlib calls for determining keyboard states. >>> Xlib thread-safety is not initialized in GTK2 widgetset. >>> >>> IMO the problem half-way to resolve - either not use Xlib calls (pure >>> GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable. >>> Or block GTK calls until Xlib call returned. >> Feel free to provide patch. >> >> zeljko > I'd like to, but i'm not a great expert in X - so i've subscribed to the > list to discuss. > > using XinitThreads at start of the program blocks GTK painting. > Forms are shown, but no text output. > > So - no way to alter XLib internals. The only way - to initialize GTK > threading in a way compatibel with X. So no way to use critical sections while calling xlib directly ? Can you open an issue and attach example ? z.

http://www.remlab.net/op/xlib.shtml

They say - there is a way

Xlib provides two groups of functions for multi-thread use:

    /* Thread-safety for global data */
    Status XInitThreads(void);
    /* Thread-safety for an individual display */
    void XLockDisplay(Display *display);
    void XUnlockDisplay(Display *display);

GNOMErs blame Xlib
https://mail.gnome.org/archives/gtk-list/2007-November/msg00122.html

I'll try to provide example.

Actually GUI does not need the multhreading.
But rendering into TBimap invokes Xlib calls as side effects. So no way to compose off-screen.

regards,
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130122/fd3e0b18/attachment.html>

Reply by email

Michael Schnell
to Anton Kavalenka: Dear Lazarus developers! I'm examining the problem disturbing me for years. GTK2…
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130123/5490a29e/attachment.html>

Reply by email

Anton Kavalenka
to Michael Schnell
Michael Schnell wrote 17 lines
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.freepascal.org/pipermail/lazarus/attachments/20130125/a62e65a2/attachment.html>

Reply by email

Mattias Gaertner
to Anton Kavalenka

Anton Kavalenka hat am 25. Januar 2013 um 12:21 geschrieben:

Show quoted text 23 lines
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.

Show quoted text 19 lines
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

Reply by email

Anton Kavalenka
to Mattias Gaertner
Mattias Gaertner wrote 51 lines
Anton Kavalenka 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?

Was reported in bug-tracker
http://bugs.freepascal.org/view.php?id=24120

with best regards,
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130325/f6691074/attachment.html>

Reply by email

Anton Kavalenka
to Mattias Gaertner: Anton Kavalenka hat am 25. Januar 2013 um 12:21 geschrieben: I guess, Michael meant,…
Mattias Gaertner wrote 60 lines
Anton Kavalenka 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 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

Reply by email

Anton Kavalenka
to Mattias Gaertner
Mattias Gaertner wrote 13 lines
> [...] > GTK2 pretends to be complete platform-agnostic interface. > Why Xlib and X is needed in GTK2 widgeset at all? For those things that were not doable with gtk2 alone. Mattias -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Are there such things?

btw current Unix printing is being rewrited using Cairo. Recent GTK2 applications depend on Cairo strictly. Why not using cairo surfaces for bitmap manipulation instead of X-Pixmap necrophilia?

regards,
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130404/b104afb9/attachment.html>

Reply by email

Mattias Gaertner
to Anton Kavalenka
Show quoted text 11 lines
[...] > > [...] > > GTK2 pretends to be complete platform-agnostic interface. > > Why Xlib and X is needed in GTK2 widgeset at all? > > > > > > > For those things that were not doable with gtk2 alone. > > > Are there such things? btw current Unix printing is being rewrited using Cairo.

Printing was never part of the LCL gtk2 widgetset.

Recent GTK2 applications depend on Cairo strictly. Why not using cairo surfaces for bitmap manipulation instead of X-Pixmap necrophilia?

I didn't implement those parts.
Feel free to send patches to replace those parts.

Mattias

Reply by email

Anton Kavalenka
to Mattias Gaertner
Mattias Gaertner wrote 28 lines
> [...] >>> [...] >>> GTK2 pretends to be complete platform-agnostic interface. >>> Why Xlib and X is needed in GTK2 widgeset at all? >>> >>> > > >> For those things that were not doable with gtk2 alone. >> >> > Are there such things? > btw current Unix printing is being rewrited using Cairo. Printing was never part of the LCL gtk2 widgetset. > Recent GTK2 applications depend on Cairo strictly. > Why not using cairo surfaces for bitmap manipulation instead of X-Pixmap > necrophilia? I didn't implement those parts. Feel free to send patches to replace those parts. Mattias -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Currently GTK2 Widgetset inherits GTK1 or they are independent? I'll try to disable X and Xlib and have a look what can be done.

Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130404/c3603478/attachment.html>

Reply by email

Sven Barth
to Anton Kavalenka
Anton Kavalenka wrote 30 lines
On 04.04.2013 16:05, Mattias Gaertner wrote: >> [...] >>>> [...] >>>> GTK2 pretends to be complete platform-agnostic interface. >>>> Why Xlib and X is needed in GTK2 widgeset at all? >>>> >>>> > > >>> For those things that were not doable with gtk2 alone. >>> >>> > Are there such things? >> btw current Unix printing is being rewrited using Cairo. > Printing was never part of the LCL gtk2 widgetset. > > >> Recent GTK2 applications depend on Cairo strictly. >> Why not using cairo surfaces for bitmap manipulation instead of X-Pixmap >> necrophilia? > I didn't implement those parts. > Feel free to send patches to replace those parts. > > > Mattias > > -- > _______________________________________________ > Lazarus mailing list > > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus Currently GTK2 Widgetset inherits GTK1 or they are independent? I'll try to disable X and Xlib and have a look what can be done.

Till around 2 years ago (don't nail me on the exact date though :) ) the GTK1 and GTK2 widgetsets shared the same files. Then they were splitted, so there is still quite a bit of GTK1 inheritance.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130404/3d194f0e/attachment.html>

Reply by email

Paul Ishenin
to Sven Barth
Show quoted text 5 lines
> Currently GTK2 Widgetset inherits GTK1 or they are independent? > I'll try to disable X and Xlib and have a look what can be done. Till around 2 years ago (don't nail me on the exact date though :) ) the GTK1 and GTK2 widgetsets shared the same files. Then they were splitted, so there is still quite a bit of GTK1 inheritance.

At the moment GTK2 interface does not depend on GTK1. They are 2 different widgetsets.

Also GTK1 is deprecated and is not maintained by core developers.

So if you will change some old code don't warry to break anything GTK1 related. You can freely use any GTK 2.8 (or lower) functionality. GTK 2.10 and upper should be used only with ifdefs.

Best regards,
Paul Ishenin

Reply by email

Anton Kavalenka
to Paul Ishenin

test application from http://bugs.freepascal.org/view.php?id=24120

Addit XInitThreads to the initialiization section of second unit after cthreads allows the test application start.

Funny enough that the windows approach - sending a message (message would be delivered in a window thread context) does not work here.

WinaAPI approach:

InvalidateRect(Display.Handle, nil, false); // notify window regions on
invalidation
Display.Update; // let the window process its messages

delivers LCL message in context of calling thread.

the only way - TThread.Synchronize(nil,Display.Refresh);

IMO queuing LCL message into main thread message queue can resolve lots of bugs.

BTW: Moving mouse over the checkbox and button sometimes display their text in the coloured painted rectangles.

regards,
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130404/9462438f/attachment.html>

Reply by email

Anton Kavalenka
to Anton Kavalenka
Anton Kavalenka wrote 26 lines
test application from http://bugs.freepascal.org/view.php?id=24120 Addit XInitThreads to the initialiization section of second unit after cthreads allows the test application start. Funny enough that the windows approach - sending a message (message would be delivered in a window thread context) does not work here. WinaAPI approach: InvalidateRect(Display.Handle, nil, false); // notify window regions on invalidation Display.Update; // let the window process its messages delivers LCL message in context of calling thread. the only way - TThread.Synchronize(nil,Display.Refresh); IMO queuing LCL message into main thread message queue can resolve lots of bugs. BTW: Moving mouse over the checkbox and button sometimes display their text in the coloured painted rectangles. regards, Anton

http://docencia.etsit.urjc.es/moodle/pluginfile.php/1668/mod_folder/content/1/Slides/GNOME/threads.pdf?forcedownload=1

Multithread programming in GLib/GTK+
GLib is thread-safety when g_thread_init is used
GDK provides gdk_threads_init too that has to be used in addition to g_thread_init, but it's not always
recommendable
Two options:

* Using *gdk_threads_init*, *gdk_threads_enter()* and *gdk_threads_leave*
* Accessing the program GUI exclusively from the main thread (where the gtk main loop is running)

The second options is preferable in most of the cases

Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130404/9b20650f/attachment.html>

Reply by email