[Top][All Lists]

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

[gmane.comp.gnome.gtk+.devel.general] Gtk+ problem with time-consuming t

From: Ben Pfaff
Subject: [gmane.comp.gnome.gtk+.devel.general] Gtk+ problem with time-consuming threads
Date: Wed, 20 May 2009 16:14:33 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Since you've brought up the idea of threading PSPP a couple of
times, I thought I'd forward out this message from the gtk-devel
list that points out a pitfall of that with GTK+:

-------------------- Start of forwarded message --------------------
From: Paul Chitescu <address@hidden>
Newsgroups: gmane.comp.gnome.gtk+.devel.general
Subject: Re: Gtk+ problem with time-consuming threads
Date: Mon, 18 May 2009 14:30:36 +0300
Organization: Null Team
Approved: address@hidden
Message-ID: <address@hidden>

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 

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.

-------------------- End of forwarded message --------------------

Positronic Functional Android Fabricated for Fighting

reply via email to

[Prev in Thread] Current Thread [Next in Thread]