On Wednesday 13 December 2006 21:52, Philip Boulain wrote: > On Wed, 2006-12-13 at 21:20 +0000, Chris Vine wrote: [snip] > > I does that by itself. You have probably not called g_thread_init() (or > > Glib::thread_init()). > > Ah, I wondered if it was supposed to. > > I haven't, no; my understanding of those is that they will enable the > Glib-specific threading system. I was kind of concerned about how that > would interact with the fact that we're already using pthreads (various > comic historic reasons). > > I have now added it, and that appears to work, at least for the Linux > build. (If it breaks for Windows, I get to see how much teeth-gnashing > can come from having to port a load of pthreads-based code over to Glib > threads can cause. ;) )
You have to call g_thread_init() before any glib functions are called, so do it early on. If you do not do that then the glib main loop (amongst other things) is not thread safe, as you have discovered. glib will use the underlying thread implementation (pthreads for Unix-like systems, and windows threads for windows). The only exception is if you are using a pthreads implementation under windows, but even that will probably work OK since the pthreads implemention will probably be a wrapper for windows threads and even if it isn't both will be using the same architecture-specific locking primitives underneath. If all else fails you can use the gthread implementation, which works on both Unix-like systems and on windows. Chris _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
