Re: deprecating gdk threads

[Pavel Holejsovsky <pavel holejsovsky gmail com>]

On 7/29/2012 12:09 PM, Matthias Clasen wrote:
> I've put patches for deprecating the gdk threading api at
> https://bugzilla.gnome.org/show_bug.cgi?id=680754
> Review appreciated.

I'd like to bring up the issue of how language bindings should cope with 
this.

Basically, the consensus from previous discussions even in language 
bindings, it is up to application authors to handle callbacks coming in 
another threads by wrapping code which needs to manipulate GTK into 
function/closure and schedule its execution via GLib.idle_add().  While 
this works generally pretty well (except that it puts the burden of 
knowing that the callback might be invoked in non-main thread to the 
application developer), there is unresolved issue with regard to 
destructors/finalizers.

Higher level languages typically use some form of garbage collection and 
thus the time when finalizers are invoked are not deterministic.  AFAIK 
python invokes finalizer callbacks from separate thread, Lua uses the 
same thread which is currently executing the Lua context, I'm not sure 
about other languages but I guess that it is similar.  In the end, this 
means that finalizers (which typically invoke g_object_unref()) can be 
invoked in the context of any thread and application/binding has 
generally little control over this.

AFAICS, this does not play nice with gdk threads deprecation, because 
one way to solve the GC finalization problems was to gdk_threads_enter() 
before entering g_object_unref() call.

One way to solve this would be to put the burden on the bindings 
implementation, and force the bindings to queue g_object_unref() calls 
using g_idle_add() to be executed in the main thread.  This seems to be 
rather ineffective though.

Another way to solve this problem might be inside GDK itself, which 
might check whether native window disposal function needs to be 
transferred to the main thread and if yes, do it internally and 
transparently.  The advantages are:

+ it is done only when needed (eg only on Win32/Quartz/whatever, only 
when called from 'bad' thread, only when g_object_unref() actually 
results in window destruction)
+ much more error prone

- the actual native window destroy function can be called 
'asynchronously' from the POV of the caller.
- someone has to implement this :-(


Thanks for reading and for any and all comments.

pavel