Re: Request of API which are thread safe/unsafe

[Tim Evans <t evans 638 gmail com>]

On 2012-01-22 17:46, Ryan Lortie wrote:
> [snip]
>
> 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).

I'm wondering how this applies to calling g_object_unref on a GTK+ 
widget. When using the pygtk bindings that's a fairly common occurrence 
as garbage collection can happen in any thread and it seems to be able 
to cause crashes and deadlocks in some cases.

Looking into one case I've found that the popup window of a GtkComboBox 
(at least when appears-as-list in true) is gtk_widget_destroy'ed in the 
finalize method. On Windows in particular doing window operations from 
any thread other than the main is a very bad idea.

For widgets that are removed from their containers but not destroyed it 
can be even worse, as finalize triggers the 'destroy' signal and things 
can get very confused when your callbacks end up running in a sub-thread.

if g_object_unref isn't safe to use in a subthread, how should pygtk be 
releasing its references?

I should mention that I'm still using GTK+ 2.16 because we haven't 
update here since the win32 fixes went into 2.24. Is this a known bug 
that was fixed already?

--
Tim Evans