Re: thread safe gtk?

[Rob Browning <rlb cs utexas edu>]

Owen Taylor <otaylor@gtk.org> writes:

Thanks for the detailed response.

> Definitely more efficient than the pipe stuff. (But the pipe stuff
> is neat because you can get things working without any modifications
> to the toolkit at all).

True, but if we *can* put it in upstream, then we might as well.

>    D) Making the locks more fine-grained. [ Probably a high
>       trouble, low gain activity ]

And for those who don't want threads in a given program, hard to do
without introducing unwanted overhead.

> The first has the major advantage that it is simple, and largely a
> complete solution. It is also mostly orthogonal to a complicated
> "change everything at runtime" solution like the third one, so that
> could be added later.
> 
> So I don't really see any problem with adding it to the 1.1
> branch of GTK+ immediately. 

This is my feeling too.  Make it a gtk-1.1 new feature, and if we need
to change it later, fine.  I doubt this will be the only feature set
changing from version to version :>

If you want or need me to do anything, just holler.

> One minor question is whether gtk_threads_enter() should be
> recursive. That is possible for LinuxThreads (and pthreads in
> general?), though it slows things down a bit. But it might also make
> things easier to program.

This is a good question.  I've never used recursive locks, but I can
see how they can help.  My opinion is that if they're not too much
overhead, then they're probably worth it.  There probably should be a
way to find out how "deep" you are, though.  If nothing else it might
help with debugging.

> I took a look at the LinuxThreads code, and it actually is FIFO.
> The problem you are seeing here is something else:

Is the LinuxThreads code the same as the libc6 code?
 
>  If a single thread does a 'unlock(); lock()' then it will
>  almost certainly get the lock back, instead of a thread
>  waiting on the lock that gets woken up after the unlock().

This I know about, but I thought that libc6 thread mutexes were
actually lifo under some conditions.  I may have misread the code.  We
have a fix here, but I should probably see if we actually need it.

Thanks again.

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