On Thu, 16 Dec 2010 21:15:36 +0000 Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > On Thu, 16 Dec 2010 12:17:51 -0700 > Kevin DeKorte <kdeko...@gmail.com> wrote: > [snip] > > I had this problem developing a GTK application on OpenBSD, it seems > > that GMutex's are not guaranteed to be recursive or non-recursive. > > > > I altered my code to work with GConditionals and worked fine. > > Perhaps, that will work for you as well. > > > > http://kdekorte.blogspot.com/2009/01/gnome-mplayer-094-will-work-with-bsds.html > > > > Kevin > > This is irrelevant, as the OP's code example does not do recursive > locking. > > It is highly unlikely that glib mutexes do not work on windows, and > that the OP is the first person to notice this. It is much more > likely that his code is defective. One suspicious feature is that > his test case for GMutex starts a thread using the windows API rather > than glib's API. That is not of itself an error, but it invites the > question whether, for example, he has called g_thread_init(). > > To the OP: you need to provide a complete compilable test case, > including your code in main(), to demonstrate the problem. You should > be able to do that in no more than 20 lines of code with something as > simple as this.
Looking at your web page, it looks as if what you were trying to do was unlock a mutex in a different thread from the one which owns (ie has locked) the mutex. It so happens that although that is not allowed by POSIX, linux-based pthreads implementations do permit this, whereas BSD sticks to the standard and does not (windows critical sections do not permit it either). You should be using condition variables in that usage, as you found out. Again, this is not relevant to the OP's test case. Chris _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
