multithreading and locking level

["Daniel Solaz" <dsolaz sistelcom com>]

I'm trying to find out how to best set up GTK bindings for multithreaded
languages.

Basically, until we have a thread-safe GTK, it seems that one either
sets up a proxy thread (I'm not going to discuss this now) OR...

>This wouldn't work for our purposes.  The second approach allows you
>to call gtk (or X) functions from any thread, but it requires some
>careful synchronization.  The basic idea is that you create an X
>protection mutex, and *no one* may make *any* X calls without first
>acquiring this mutex.  So if you want to draw a line, you have to say:
>...
(Rob Browning, 'Re: thread safe gtk?', May 8th)

As Mr. Browning says, there's more to it that just happily locking and
unlocking some Gtk.Lock as needed.

Here's what I'd like to try, based on other toolkit's approach as seen
elsewhere:

Would it be safe to have *each* widget wrapper inherit from MUTEX, and
acquire this lock (not the global Gtk.Lock) before use?
Since widgets form a tree-like hierarchy, before affecting widget w I
guess I would need to lock the whole branch starting at w so that no
concurrent calls to Gtk act on the same widget (or a related one) at the
same time.
Locking would have to be done starting at the leafs of the branch, and
proceed upwards until w.lock can be acquired (that is, first w's
children, recursively, then w).  Unlocking would be done from w
downwards, then.

In short, if two threads are working on completely unrelated parts of
the widget tree, can they work in parallel?  Or Xlib/GTK simply won't
accept it?

This is more an experiment than anything else.  Probably too much
overhead, BTW.  But I'd like to try.

Thanks in advance.

-Daniel