Re: Gtk+ problem with time-consuming threads

[Paul Chitescu <paulc voip null ro>]

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.

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.