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

[Rob Browning <rlb cs utexas edu>]

Tony Gale <gale@daedalus.dera.gov.uk> writes:

> Although the question/answer isn't limited to GTK and is applicable to
> most X toolkits, I'll add it to the FAQ (or rather add it to the
> queue I have of things to go in the FAQ - should get time to do some
> work on it later this weekend).

OK, feel free to edit it as much as you like.

There's one bit missing though which someone just pointed out to
me.  I forgot to mention how you make sure that other threads get a
chance to do any UI related stuff if the main event loop's holding the
mutex.

Here's what I said:

You also need to install a *work proc*, as opposed to an idle proc
that does something like the following:

  gint
  UI::_primary_work_proc(gpointer /*client_data*/) { 

    if(_user_work_proc) {
      THREAD_SPECIFIC(_xprotect.release());
      const bool finished = _user_work_proc(_user_work_proc_data);
      if(finished) {
        UI::set_work_proc(NULL); 
      }
      THREAD_SPECIFIC(_xprotect.acquire());
    }

    THREAD_SPECIFIC(_xprotect.release());
    THREAD_SPECIFIC(PThread::sleep(_sleep_time));    
    THREAD_SPECIFIC(_xprotect.acquire());
    return(true);
  }

This particular work proc accomodates the possiblity that the user
might want to install their own work proc since we use it here in our
cheap little UI wrapper.  Then it makes sure that other threads have a
chance to use the UI by releasing the mutex, sleeping, and then
reacquiring it.  By adjusting _sleep_time, you can decide how much
time other threads are allowed access to the UI.  This seems to work
fine for our purposes.

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30