Re: gdk threads ...

[Paul Davis <paul linuxaudiosystems com>]

On Mon, Mar 5, 2012 at 9:34 AM, Andy Wingo <wingo pobox com> wrote:
> Heya,
>
> On Mon 05 Mar 2012 14:07, Ryan Lortie <desrt desrt ca> writes:
>
>> On Mon, 2012-03-05 at 12:11 +0000, Michael Meeks wrote:
>>>      Does that mean you're removing gdk_threads_enter and leave and the
>>> semantics around that ? is there some cunning new scheme proposed to
>>> intercept the mainloop and ensure that events / idle / timeout emissions
>>> hooked in by the toolkit can have applications add lock/unlock pairs ?
>>
>> We're not removing -- only deprecating.
>>
>> The removal will come in GTK4.  There will be no replacement
>> functionality -- you will just be expected to do all your interaction
>> with the toolkit from the main thread (ie: dispatching results via
>> idles).
>
> You're sure this is a good idea?
>
> I really liked Java-GNOME's approach to the issue:
>
>  http://blogs.operationaldynamics.com/andrew/software/java-gnome/thread-safety-for-java
>
> Would this mode of interaction with GTK+ not be supported in the future?

well, lets think about this for a moment. you've got some worker
thread that has done some work (probably computational, but possibly
i/o based) and now as a result it wants to change the appearance of
some part of a window owned by the process. there are 2 possible
scenarios:

1) the main GTK thread is currently busy, and thus the worker thread
would have to block anyway
2) the main GTK thread is blocked in its main event loop, and so the
worked thread could potentially make GTK/GDK calls itself

in the first case, i don't see what is gained by having the worker
thread block rather than just schedule an idle callback.

in the second case, it initially seems silly to schedule an idle
callback when you could just make the relevant calls to GTK/GDK
inline. but lets think a little bit about what those calls are going
to do. ultimately, they are going to invoke gtk_widget_queue_draw() or
its cousins. they are not not going to actually draw on the window,
since that only happens during expose event handling. so in fact, the
window redraw won't take place inline unless the worker thread also
invokes an iteration of the gtk main loop. this is now (to me)
starting to seem like a worse and worse idea. instead, just push all
the GTK/GDK calls into a function that can be executed as an idle
callback. call g_idle_add(). the main GTK thread wakes up, executes
the code, hits the idle processing loop, synthesizes expose events,
redraws the window.

the downside is that every worker thread now requires at least one
additional function to be invoked from an idle callback. compared to
the upside: no locking protocol, and better enforcement of a
model/view/controller design - this seems like a small price to pay.