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

[Rob Browning <rlb cs utexas edu>]

Ian Main <slow@intergate.bc.ca> writes:

> I can see the elegance of using multiple threads to do something like
> realtime video, but I'm sure there's ways to divide the labour without
> multiple gtk threads.. but I could be wrong :)

It's absolutely true that most tasks can be done equivalently without
using multiple threads, but there are several reasons why threads may
be an improvement either with respect to design or performance:

[It's late and all this is off the top of my head so I'm sure others
can provide better examples...]

  1) The problem may break down much more naturally in terms of
     separate threads, making the resulting code much simpler.

     Example (trivial): five timers updating every 10th second

     void run_timer(GtkWidget *progress_bar) {
        double current_time;
        while(!times_up(progress_bar)) {
          update_progress(current_time += increment);
          pthread_sleep(0.1);
        }
     }

     launch_thread(run_timer, bar1);
     launch_thread(run_timer, bar2);
     launch_thread(run_timer, bar3);
     launch_thread(run_timer, bar4);
     launch_thread(run_timer, bar5);

     This is to some extent a more elegant solution than having one
     thread maintain all the timers, and it scales well.  It's easy to
     handle things like a per/timer suspend or cancel button (just
     suspends or kills the thread as appropriate), etc.

  2) The problem may be handled more efficiently by threads.

     Example: multiple processor machine where gtk can be doing it's
     computation for each thread calling it's functions on different
     CPU's

     Example: multiple X servers or displays -- gtk can be sending
     multiple requests (one from each thread) to different servers
     when possible (similar to the multi-CPU example).

     X servers are kind of like disks or the net, and benefit from the
     same IO/CPU multiplexing that other IO subsystems do.  On the IO
     side, if you need to read 10 files, you're probably going to get
     all the data much faster if you launch 10 threads, each one
     asking for one file, than if you ask for them one at a time with
     a single thread (especially if there's a good SCSI array
     underneath), and using multiple threads is much less awkward than
     managing umpteen reads on 10 files with non-blocking IO and
     select from a single thread.

Oh well, that's enough for now.  I'm sure there are other reasons, but
I'm to tired to come up with them at the moment.
-- 
Rob