Re: thread safe gtk?

Owen Taylor <> 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

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):

gtk_threads_enter() { pthread_mutex_lock(&gtk_lock_mutex); }

gtk_threads_leave() { pthread_mutex_unlock(&gtk_lock_mutex); }

gtk_threads_main() {

  while(!gtk_should_quit()) {

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.


Rob Browning <>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]