Re: thread safe gtk?

[Owen Taylor <owen gtk org>]

> > 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.

Looking into them in more detail, they have a ~15% overhead, which,
considering that they are pretty fast to begin with isn't too
important. However, the interface for recursive locks doesn't seem to be
very standardized yet. (LinuxThreads uses pthread_mutex_setkind,
other places it seems to be pthread_mutex_settype, etc.) So it
might be better to stick with non-recursive locks for now.
 
> > 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?

I was looking at the LinuxThreads code included in glibc-2.0.7
  
> >  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.

Perhaps it has changed? The current code seems to be pretty
clearly FIFO. (Its queues keep separate head and tail pointers,
enqueue at the tail and dequeue at the head).

Changing topics:

I went ahead and implemented the basic unlock(); select(); lock();
strategy in GDK, and noticed that there is a problem with that - 
namely idle functions.

If one of the subsidiary threads does something that results
in an idle function being added, the idle function won't
be processed until the main loop wakes up out of the select()
of its own accord.

I can think of several solutions:

 - Send a signal to the main thread. Probably portability problems.
   (Especially since LinuxThreads uses SIGUSR[1/2] itself.

 - Use a pipe to signal the main thread to wake up. Probably the
   best approach. Not terribly efficient but you only need to
   do this when adding the first idle handler.
 
 - Handle the idles in a separate thread to avoid having to
   wake up the main thread at all. Probably a waste of a process,
   and somewhat tricky synchonization.

So it isn't quite as simple as it seemed.

Regards,
                                        Owen