Re: [gtk-list] problems with Gtk_Entry and threads

[Rob Browning <rlb cs utexas edu>]

Brian Alexander Martin <briam@cats.ucsc.edu> writes:

> I'm not calling any gtk functions from my opengl thread. 
> All I'm doing there that affects the dislplay is calling glXSwapBuffers,
> which then draws into the drawing area. 

I wouldn't count on the fact that glXSwapBuffers is safe without
semaphore protection with gtk code running in another thread.

> As far as I can tell, It's hanging on a lock somewhere in the X code.  If
> I take out the call to XInitThreads() in main, I'm able to type into the
> entries for a little while, but then I end up getting something like this:

Just to be sure, do you check the return value of XInitThreads to be
sure you're getting thread aware X libs?  Also do you compile *all*
your code, including the GTK libs with -D_REENTRANT (assuming this is
libc6)?

> No other widgets act strangely.  I've ifdef'd all the threading stuff, and
> when I compile without it everything works.  (no XInitThreads and no
> threads either)
> 
> So why would XInitThreads cause the entry widget to bomb?

I would suggest either putting mutex protection around your call to
glXSwapBuffers, and using the same mutex around *all* other uses of X,
including all GTK calls, and gtk_main.  You have to be a little
careful about how you do this -- you have to remeber you'll be holding
this mutex during any callbacks, and you may need to install an idle
handler that releases the mutex for a while now and then.  Also, I'm
not sure, but you may need to avoid gtk_main, and use your own calls
to gtk_main_iteration.  A while back, I posted the solution we use
here that allows you to make gtk calls from any thread as long as you
respect a global mutex.  You can probably find it in the archives.
It'll be clearer than I can be off the top of my head right now.

An alternate (and simpler) approach would be to remove the
glXSwapBuffers call from the other thread, put it in an idle handler,
and just set a global whenever you want the gtk thread to call it.
There are a million variations on this approach.  Also, I presume
you're making other GL calls from the non GTK thread.  If so, I
wouldn't count on the fact that they're not going to make X calls that
might interfere with (i.e. lock up) GTK.

Good luck.

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