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

Reply via email to