Re: thread safe gtk?

[Owen Taylor <otaylor gtk org>]

Rob Browning <rlb@cs.utexas.edu> writes:

[...]

> > Looks like i still have to use gdk_input_add to make it monitor in its 
> > own select my pipe so i can wake it up.
> > But i think that useing your locking around the X calls will simplify
> > the calls for complex multithreaded programs. maybe it should be come:
> >
> > #define XSTART write(Xpipe[1],"x",1);lock(xlock);
> > #define XEND   unlock(xlock);
> >
> > somewhere in the beginning:
> > pipe(Xpipe);
> > gdk_input_add(Xpipe[0],GDK_INPUT_READ,threadcall,0);
> >
> > threadcall(){
> >   unlock(xlock);
> >   read(Xpipe[0],&c,1);
> >   lock(xlock);
> > }
> >
> > If this doesn't work a heavier construction with threadconditions is
> > possible but i'm just trying to get rid of that one... The problem with
> > thread conditions is that you have to use the same threadcondition in both
> > threads...
> 
> Now this is quite clever.  If I understand correctly, you're having it
> select on the actual X pipe, right, so that you'll wake up whenever
> there's something for X to do?  If so, that would definitely be a
> better approach.  

It is definitely a clever approach. The "Xpipe" here has nothing
to do with connection to the X server (I'm not sure if that is
what you mean by "actual X pipe"), it is just a device for
communicating with thread that is blocking in the mainloop select().

There is the problem here, addressed in the next message, that the
mainloop thread may reacquire the lock instead of letting the
subsidiary thread get the lock. So it does need to get a bit fancier.

> I'm wondering if it might be worth wrapping all this
> stuff up into a small API for people using threaded GTK, or if it's
> even possible to do that generally.
> 
> 
> Something like
> 
>   gtk_threaded_main();
>   gtk_thread_enter();
>   gtk_thread_exit();
>   etc...

I just fooled around with a bit and created something like this:

  ftp://ftp.gtk.org/pub/users/otaylor/gtkthreads-0.1.tar.gz

(Calling it just gtkthreads is pretty presumptious, considering
how little I know about threading). It seems to work reasonably
reliably in limited testing.

The best long term approach is most likely to modify GTK to 
optionally do:

#ifdef GTK_USE_PTHREADS
  gtk_mutex_unlock (&gtk_mutex);
#endif
  select (...)
#ifdef GTK_USE_PTHREADS
  gtk_mutex_lock (&gtk_mutex);
#endif

Which allows other threads to get the GTK lock without having
to communicate with the main thread.

Regards,
                                        Owen