Re: Gtk+ problem with time-consuming threads

[Rob Taylor <rob taylor codethink co uk>]

Paul Chitescu wrote:
> On Monday 18 May 2009 14:12:00 Alexander Larsson wrote:
>> On Thu, 2009-05-14 at 10:18 +0300, Tor Lillqvist wrote:
>>>>> You can't use GTK+ from multiple threads on Windows. That is just how
>>>>> it is. It is a consequence of GTK+ originally being written just for
>>>>> X11.
>>>> I always thought it was because of how the Windows event model works.
>>> Yes, exactly. That is what I mean. With its dichotomy of "sending" and
>>> "posting" of messages, creator thread -aware windows, etc, it is quite
>>> different from X11 which is a network protocol. The GTK+ code was
>>> written originally only for X11. That it was possible to port it to
>>> Windows is in retrospect a bit surprising, I must say, even though I
>>> did it myself.
>>>
>>> (I don't know how toolkits that have been written from scratch with
>>> both X11 and Windows in mind (like presumably Qt) then differ in the
>>> general working of their low-level machinery, but I assume they do in
>>> some significant way.)
>> It might actually be interesting to see how Qt handles this, maybe they
>> have some interesting approach that could be useful for Gtk+ too.
> 
> Qt handles such a situation in an uniform but stupid way. In Qt (on any 
> platform) every object is tied to its creator thread and signals/slots can be 
> connected only between objects from the same thread. This is a major 
> limitation.

I believe you can connect signals/slots between threads on Qt, but it
works by marshalling the signal data and then re-emitting the signal
from the appropriate mainloop. The emitter may continue or block until
the signal has been delivered. Its kinda cute.

http://doc.trolltech.com/4.5/qt.html#ConnectionType-enum

Thanks,
Rob

> Also on Qt calling the native file selection box in synchronous mode blocks 
> the calling thread since it doesn't call the idle loop. This is documented. 
> Usually an application would run these native calls in a separate thread and 
> somehow proxy the result back to the caller.
> 
> The fact Gtk+ behaves differently depending on platform makes developer's job 
> much more difficult. A multithreaded program designed and tested on X11 needs 
> a full redesign to support Windows. The opposite is not true but I suspect 
> there are very few that start developping Windows programs with Gtk.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


-- 
Rob Taylor, Codethink Ltd. - http://codethink.co.uk