On Sun, 2008-10-26 at 00:25 +0800, Peter Cai wrote: > Hi all, > > I'm writing a COM program on windows but I'm not quite familiar with C++. > thus I decided to use mostly C instead and I want to use GLIB in it. > > But I got one problem. Is GLIB thread safe? generally speaking no. let me give you some background. glib was originally developed on POSIX conformant platforms in which process creation is cheap and it has been more common for people to use fork() than multiple threads. it is traditional in these environments to not burden library code with mutexes and other sync-related primitives because the common case is generally non-threaded. applications that are multithreaded get to do their own explicit locking, without causing overhead for the common case. there are many other examples of this, the most prominent being X Window. win32 has traditionally been more or less the opposite: process creation is expensive, and apps tend to be multithreaded rather than using fork(). as a result, library code tends to includes mutexes etc. so that the common case (multithreaded code) works, even though its costs uni-threaded code quite a lot in performance terms. which one is right? it hardly matters. glib doesn't use implicit mutexes etc. to provide thread safety - that is up to your app. the thread init calls are there because there are (internal) parts of glib that your app cannot protect itself. if compiled and used appropriately, glib will ensure that these are also thread-safe. --p _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
