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

[Elliot Lee <sopwith redhat com>]

On Tue, 29 Jul 1997, Erik Troan wrote:

> > The easiest way to do this is the global mutex. This doesn't help
> > performance very much, though.
> 
> I wonder where gtk spends most of its time? It seems pretty efficient, so
> I'd *guess* that the real time sinks are in Xlib and the Xserver. If that's
> the case, a single mutex is all you need. 

I don't know if Xlib has its own global mutex - if it does then obviously
a global gtk/gdk mutex would be the best thing.  But if Xlib can be truly
called reentrantly, that means instead of having one thread with an X
request in progress and other threads blocking until that request
completes, we could have multiple threads awaiting responses from the X
server or just doing general processing. 

<more random thoughts>
Perhaps a tree of mutexes, hmm...
	if doing operation on a widget, that automatically locks
	all children as well.

We don't even need to exclude other threads from reading data structures,
just writing to them needs to be locked. Perhaps a counter that lets us
know how many threads are reading a resource, and a mutex for locking
access (to be used by threads which need to write to a resource).

All this #ifdef'd into place, of course.

Can the increment and decrement operators be assumed to be atomic?

What's the best way to suspend a thread until the read counter == n?
</more random thoughts>

> Also, most multithreaded windowing apps dedicate a single thread to the
> user interface, which would also suggest this approach. I suspect that
> any type of fine-grained locking on gtk would be a huge loss?

Most multithreaded windowing apps currently available may dedicate one
thread, but we don't want to limit people to this approach! :-) I think
the best solution depends on knowing how well Xlib implements reentrancy.

-- Elliot					http://www.redhat.com/
What's nice about GUI is that you see what you manipulate.
What's bad about GUI is that you can only manipulate what you see.