[Gtk-sharp-list] Still can't show config dialog, but can show anything else

Michael Hutchinson m.j.hutchinson at gmail.com
Sat May 12 16:53:16 EDT 2007

On 5/12/07, Eskil Bylund <eskil.bylund at gmail.com> wrote:
> You are making those Gdk threads call to make it more stable when
> running on Windows, right? Ideally they shouldn't be needed because
> the Gdk lock is meant to be used when calling Gtk from multiple
> threads, and you aren't. Your problem now is this:
> "Idles, timeouts, and input functions are executed outside of the main
> GTK+ lock. So, if you need to call GTK+ inside of such a callback, you
> must surround the callback with a
> gdk_threads_enter()/gdk_threads_leave()   pair. (However, signals are
> still executed within the main GTK+ lock.)"

Interesting, I wasn't aware of the locking in GTK+. That almost
contradicts the GTK# documentation (and the GTK# Responsive
Applications page), in that idles and timeouts aren't necessarily
quite as simple as they appear to be. However, my reading of this is
that there's only a problem when accessing GTK *directly* from
multiple threads. Also, the GTK+ docs say that the lock won't work on
Win32 at all -- I guess this explains why little mention is ever made
of accessing GTK# directly from multiple threads, and hence why
simplistic use of Idle and Timeout should not be an issue.

Unless Aaron is starting other threads which are attempting to use
GTK, I don't see that not using the lock is an issue here.

I've fiddled about with the code on Ubuntu Feisty, and it has some
threading issues. The timer code is waiting for showMessage(s) to
return, so the timer doesn't start counting till that happens.
Wrapping the showMessage call in a Gtk.Application.Invoke fixed that.

I also find that the program hangs on closing the dialogue unless I
remove the Gdk.Threads.Init call, and this can alternative be fixed
hackily by adding a Gdk.Threads.Leave at the end of showMessage.
Although I'm a threading novice, I'd say this implies a double-locking
somewhere in GTK. Best just to avoid GDK multithreading IMO.

BTW, why the use of Gdk.Threads.Enter and Leave around Application.Run?

Michael Hutchinson

More information about the Gtk-sharp-list mailing list