Re: Request of API which are thread safe/unsafe

[Ryan Lortie <desrt desrt ca>]

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