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

[John Darrington]

Thanks.

I won't pretend to understand the details of everything that's being
discussed in that thread, but based on what I have read elsewhere, and
my experiences to date, I think the gist of it is that Gtk's 
underlying Gdk library can only be called from a single thread (or
else must be synchonised with gdk_threads_enter/gdk_threads_leave). In
other words concurrent Gdk calls aren't permissible.

However, that doesn't mean that any application which uses Gdk/Gtk+
can't have multiple threads.   My idea (one of them at least) is to
have all the Gdk operations comming from a single thread, and in
second thread, the pspp backend could be running.  One advantage of
this, is that when running a procedure on a very large dataset, the
gui would remain responsive while the dataset is being processed.
Currently it just hangs until until the procedure completes.

J'

On Wed, May 20, 2009 at 04:14:33PM -0700, Ben Pfaff wrote:
     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 --------------------
     Path: news.gmane.org!not-for-mail
     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 
     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.
     
     -------------------- End of forwarded message --------------------
     
     -- 
     Positronic Functional Android Fabricated for Fighting

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature