Re: gdk threads ...

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 25 Apr 2012 15:10:18 -0400
> the issue is not the source. its *attaching* it that is the potential
> source of problems. g_source_attach()'s docs make no mention of
> whether it can be done safely from another thread. that's also true of
> the layers above it like g_timeout_add() etc.
> 
> where is the explicit declaration that you're referring to?

If g_source_attach() is not thread safe, then g_idle_add() is not
threads safe: it invokes g_source_attach() in the same way that the
other *_add()'s do. Idle sources are just another source, albeit ones
which fire immediately they are reached by the dispatcher in the event
queue. If you look at the source you will see that g_source_attach()
invokes the main loop's mutex and that the main loop is thread safe.

The documentation states: "GLib itself is internally completely
thread-safe (all global data is automatically locked), but individual
data structure instances are not automatically locked for performance
reasons.  For example, you must coordinate accesses to the same
GHashTable from multiple threads. The two notable exceptions from this
rule are GMainLoop and GAsyncQueue, which are thread-safe and need no
further application-level locking to be accessed from multiple threads.
Most refcounting functions such as g_object_ref() are also thread-safe."

Chris