hi Naveen, On Mon, 2012-01-16 at 14:50 +0530, naveen yadav wrote: > I want to know which all API are multithread safe. As we have in Glibc. In general, GLib strives for all API to be threadsafe with respect to global state. We generally avoid functions returning pointers to static storage that gets freed on the next call, for example. I cannot think of any exceptions to this rule. Many API in GLib deal with particular objects (like hashtables). These API are safe to call in different threads at the same time on *different* objects, but access to the same object from multiple threads requires locks. There are a few exceptions to this rule. GAsyncQueue comes to mind (because it has its own locking built in). Additionally, it's typically safe to call g_object_ref() and g_object_unref() on the same object from multiple threads at the same time, as well as functions like like g_object_get/set_data(). We recently also added support for threadsafe weak references. GTK is another story. There is quite a lot of global state here and almost nothing is threadsafe. All interactions with GTK should be done from the main thread of the program. If you have worker threads, they should coordinate with the main thread in order to make calls into GTK (by using g_idle_add() for example -- the callback function is always run in the main thread). We have a feature called 'gdk threads' that can also be used to make calls to GTK from other threads, but this is not portable and its use is generally discouraged (and there is discussion about removing it from the next version of GTK). As an answer to the related question of which functions are safe to call from signal handlers, the answer is "effectively none". Cheers _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
