Re: multithreaded apps

[otaylor redhat com]

Nathan Clegg <nathan@islanddata.com> writes:

> What's the best way to handle multithreaded GTK applications?  Should the
> non-main threads just be generating events for the main thread to handle
> graphically?  Can I generate real GTK events or will that cause the
> callback to be in the non-main thread?

GTK+ does have threading support. It basically consists
of one big manual lock around all of GTK+/GDK, but I think 
should be fairly useable despite that. It hasn't
been extensively tested, but that isn't going to
improve unless people try it out.

(There are a couple of bug fixes that will
be in the GTK+-1.2.2 release that will be appearing
any hour now.)

You can do some sort of neat inter-thread IPC stuff using
the GTK+ - for instance, to execute a function in
the main thread, you can, in a subsidiary thread, do:

 g_idle_add (some_func, some_data);

Regards,
                                        Owen

Here's a few notes from docs/Changes-1.2.txt that cover the
basics of using threads with GTK+. It probably could
be a bit more coherently organized, since it was meant
originally as "here is what has changed since the
first prototype of thread support".

====
* The thread safety in GTK+ 1.2 is slightly different than
  that which appeared in early versions in the 1.1
  development track. The main difference is that it relies on 
  the thread primitives in GLib, and on the thread-safe 
  GLib main loop.

  This means:

   - You must call g_thread_init() before executing any
     other GTK+ or GDK functions in a threaded GTK+ program.

   - Idles, timeouts, and input functions are executed outside 
     of the main GTK+ lock. So, if you need to call GTK+ 
     inside of such a callback, you must surround the callback
     with a gdk_threads_enter()/gdk_threads_leave() pair.

     [ However, signals are still executed within the main
       GTK+ lock ]

     In particular, this means, if you are writing widgets
     that might be used in threaded programs, you _must_
     surround timeouts and idle functions in this matter.

     As always, you must also surround any calls to GTK+
     not made within a signal handler with a 
     gdk_threads_enter()/gdk_threads_leave() pair.
    
   - There is no longer a special --with-threads configure
     option for GTK+. To use threads in a GTK+ program, you
     must:

      a) If you want to use the native thread implementation,
         make sure GLib found this in configuration, otherwise,
         call you must provide a thread implementation to
	 g_thread_init().
   
      b) Link with the libraries returned by:
 
           gtk-config --libs gthread

         and use the cflags from:

            gtk-config --cflags gthread

     You can get these CFLAGS and LIBS by passing gthread
     as the fourth parameter to the AM_PATH_GTK automake
     macro.
======