Re: thread safe gtk?

[Rob Browning <rlb cs utexas edu>]

Owen Taylor <otaylor@gtk.org> writes:

> - Main thread M gets the lock, goes back to the main loop,
>   sees there still is one byte in the pipe, releases the
>   lock and waits on the condition variable. But neither
>   A nor B wants the lock now, so the main loop hangs.

Which is why each thread needs to remove a token from the pipe before
it returns from its critical section rather than letting gtk_main do
it.  The way it's structured right now that doesn't happen, but it
should.

That gets me around to my main question which is, why do we need a
pipe at all?  As long as we're providing a gtk_threads_main anyway,
why not just do something like this?  (Note that I haven't had time to
consider this extremely carefully, so I may be overlooking something):

void
gtk_threads_enter() { pthread_mutex_lock(&gtk_lock_mutex); }

gtk_threads_leave() { pthread_mutex_unlock(&gtk_lock_mutex); }

void
gtk_threads_main() {

  while(!gtk_should_quit()) {
    pthread_mutex_lock(&gtk_lock_mutex);  
    gtk_main_iteration();
    pthread_mutex_unlock(&gtk_lock_mutex);  
  }
}

Now everyone uses this enter/leave pari and just queues up (blocks) on
the mutex until it's their turn; no condition variables, sleeps, or
other stuff needed.  The mutex keeps track of who wants in and whose
turn it is...

For fairness, this relies on pthread_mutex_lock to be (fifo) which was
not true last time I checked libc6 (POSIX doesn't mandate this).  I
believe it was actually LIFO (ugh) when I looked at the source.
However, If we think this general approach is good, I can provide
wrapper code I've already written which will guarantee fifo
locking/unlocking behavior.

Thanks

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