On Sun, 13 Sep 2009 18:35:06 -0400 (EDT) Marshall Lake <ml...@mlake.net> wrote: > I've taken some time to check the mutex and locks/unlocks between the > secondary thread and the idle function. All appear as it should. > The locks/unlocks are being applied in an orderly fashion and as they > should be, and there are no recursive locks. The program flows as it > should. > > I still feel my problem has something to do with the secondary thread > and idle function working together but at this point I'm not sure > what to check next.
I am only familiar with glib on unix-like systems, where GMutex/GThread/ GCond are thin wrappers for their pthread counterparts. g_idle_add() is implemented differently in windows as well, with a windows event object rather than a unix pipe. If you are using windows, possibly the contortions necessary to fit windows threads into a pthread-type model is causing the difficulty. You may want to look at the glib source code: as a random thought, possibly the idle handler has to be dispatched under a lock (normally a no-no) in which case it offers up new possibilities of deadlocks. But this is pure guess-work. I assume you have made the main loop thread-safe by calling g_thread_init()? Chris _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list