Re: Glib 2.32.x, Win32 and threading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> On 2012/07/04 at 05:22 PM, Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 04 Jul 2012 13:18:18 +0200
> "Martin Schlemmer" <Martin.Schlemmer@xxxxxxxxx> wrote:
>> >>> On 7/4/2012 at 10:30 AM, Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx>
>> wrote:
> [snip]
>> > GTK+/GDK has never been thread-safe on Win32.  If the GDK global
>> lock
>> > appeared to work for you in the past you just got lucky.  From the
>> > documentation at
>> > http://developer.gnome.org/gdk/stable/gdk-Threads.html :
>> > 
>> > "GTK+ is "thread aware" but not thread safe * it provides a global
>> lock
>> > controlled by gdk_threads_enter()/gdk_threads_leave() which protects
>> > all use of GTK+. That is, only one thread can use GTK+ at any given
>> > time.
>> > 
>> > "Unfortunately the above holds with the X11 backend only. With the
>> Win32
>> > backend, GDK calls should not be attempted from multiple threads at
>> > all."
>> > 
>> > In due course
>> gdk_threads_init()/gdk_threads_enter()/gdk_threads_leave()
>> > are to be deprecated in the X11 backend, although that is not
>> relevant
>> > to your code.
>> > 
>> > Win32 users (and in due course X11 users) should use
>> > g_idle_add()/g_idle_add_full() to send event callbacks from worker
>> > threads to the gui thread which invoke the GTK+ functions you want
>> to
>> > call. With glib < 2.32, you will need to call g_thread_init()
>> > (g_thread_init() is not needed on glib >= 2.32 and is a no-op.) 
>> This
>> > also happens to be a much cleaner design than using the GDK global
>> lock.
>> > 
>> > The FAQ on this is, I agree, misleading - I should file a
>> documentation
>> > bug.
>> > 
>> 
>> I understand this, and that is why I modified the example to do
>> exactly that - use g_idle_add().
> 

Hi Chris, thanks for the reply - I totally mis-read/understood the quote and your reply.

> It didn't.  The code you posted makes calls to gdk_threads_init(),
> gdk_threads_enter(), gdk_threads_leave() and gdk_threads_add_idle().
> 

I first tried g_idle_add(), then commented it and added gdk_threads_add_idle() for testing, but see below.

> As I have said, it is pointless trying to invoke the GDK lock
> (which these do) in Win32 and in your case seems to have created a
> deadlock.  Remove these gdk calls, refactor your code to pass events,
> use g_thread_init() and g_idle_add(), and it should work.
> 

And this is where I guess I totally fell off the bus. All my code does adhere to above *except* that I thought gdk_threads_init() was still required with threads even if you only made GDK calls from the main thread.

Anyhow, I am now aware of the problem, but for sake of legacy code that might still use gdk_threads_init(), should I file a bug with the patch, or maybe to at least one to add a warning/abort in gdk_threads_init() for Win32 so that others who run into this problem will not be burnt?


Thanks,
Martin




Vrywaringsklousule / Disclaimer:  http://www.nwu.ac.za/it/gov-man/disclaimer.html 

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list


[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux