Re: [gtk-list] Re: thread safe gtk?

[Square Avenue <dfinton d umn edu>]

On 8 May 1998, Sami Juhani Kallio wrote:

> I think that the proportion of threaded (GUI) programs on Unix is only
> small because of the missing support from GUI toolkits (and because
> thread implementations are quite new anyway). I see a big potential on
> threaded applications. Almost every application I use would be much
> better if multithreaded.

Almost any app that needs to do heavy work (like, for instance, a fractal
renderer:) would logically benefit from having threads.  My current
solution, gtk_idle_add and gtk_idle_remove, works decently but now I am
running into problems, like how to calibrate the idle function in a way so
that it doesn't take so long as to slow down the GUI, and not too fast as
to create too much overhead by doing too much work calling the idle loop,
and not enough work actually doing "real" calculations.  Add that to the
fact any timing results I obtain could be skewed if the average load of
the computer system in question was anything other than 0.00.

After reading this thread, I'm thinking of taking the multi-threading
route after all.  While one thread is actually doing the massive
calculation work, a slave thread simply paints the pretty pictures
onto the screen.  Hmmm, back to the drawing board.  :)

> I understand the reasons complexity, overhead, and manpower, but I
> would think that two of them are not so bad. You could move the
> complexity from the applications into the library, which is usually
> only a good thing. And even when using the manpower in library
> development, you will save that in applications programming. The issue
> of overhead still remains and affects the application which have no
> reason to be multithreaded. I don't know how big the overhead would
> be, but once designed carefully in the library, all the pain would be
> away from the application developing.

Ah, the eternal question of balancing power and overhead.  :)

I do believe manpower issues are irrelevent, too, since any time used to
make GTK thread-safe will be saved many-fold in app development.  This is
especially true since every other widget set and their grandmothers
support threading (including, God forbid, Win32).  Someone out there
thinks it's a good idea.

I don't think complexity is much of an issue.  If complex projects were
outside of the realm of free software (oooops open source), there wouldn't
be a Linux, GIMP, or GTK.  :)

Overhead?  Hmmm... locking a variable once for every GDK call would be
disasterous, but what about locking a particular widget whenever a redraw
event is called for it, or some such?

I'm still learning about this stuff, so bear with my glaring errors.  :)

> In my opinion, this is also a very important issue if we want GTK to
> be a really good alternative. For example, Motif 2.1 and Win32 are
> already thread safe.

I agree.

Hmmm... I'll wait until Debian 2.0 comes out... I'm thinking about getting
it (I've never seen what it's like, and since I will be a paid consultant
for Linux systems, this might be a GoodThing(tm) for me to do).  Glibc,
here we come!  :)

                                      - Dave

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Name:  David Finton                  | "All free software is in Beta.  If
 Email:  dfinton@d.umn.edu             |  there is a free software package
   Web:  http://www.d.umn.edu/~dfinton |  bearing the version number 1.0 or
                                       |  greater, it is obsolete and must
                                       |  be replaced immediately by a
                                       |  newer, better Beta version."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-