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 <[email protected]> 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: [email protected] Message-ID: <[email protected]> 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 _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
