On Mon, 14 Sep 2009 18:02:25 -0400 (EDT) Marshall Lake <ml...@mlake.net> wrote:
> I'll be a son-of-a-gun. Removing the gdk_* calls fixed the problem. > It's something I should have known. The GDK global lock is difficult to use correctly. All GTK+ signal callbacks are entered holding the lock (as is gtk_main(), although the lock is relinquished by the main loop before calling glib timeouts, idle handlers, gio callbacks and the like). This means that you usually need to treat the GDK global lock as Lock 1 and never call gdk_threads_enter() holding another lock, and to ensure that any idle handlers or other main loop callbacks release their own locks before returning, so as to allow GTK+ to reacquire the global lock for its signal handlers in the correct order. I expect that one or other of those may have been the problem. As I say, it is best to avoid the global lock if you can, and you can if you only allow worker threads to access GTK+ through idle handlers. You are obliged to do that under windows anyway, as the global lock does not work with windows, so it is the more portable approach. Chris _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
