Re: deprecating gdk threads

On 7/29/2012 12:09 PM, Matthias Clasen wrote:
I've put patches for deprecating the gdk threading api at
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]