Re: Xlib-error in threaded GTK+

[Owen Taylor <otaylor redhat com>]

Tomas Berndtsson <tomas@nocrew.org> writes:

> Owen Taylor <otaylor@redhat.com> writes:
> 
> > > > I have had this problem aswell.
> > > > A second thread is writing to some shared memory that
> > > > the X thread reads.
> > > 
> > > Well, it's not shm-memory in my case, but they do share memory areas,
> > > which has been allocated with malloc (not g_malloc).
> > 
> > This can't cause this sort of problem - an error like this almost
> > certainly indicates that you are making X calls from the second 
> > thread - probably there is some code path that you aren't
> > expecting which does it.
> 
> Oh, shit, that's right.. a small little thing, I just came to think
> of..
> 
> So, how do I avoid the error? Do I put another pair of
> gdk_threads_enter/gdk_threads_leave around the GTK+ calls in the
> second thread?

Well - the whole point of gdk_threads_enter() / gdk_threads_leave ()
is to allow multiple threads to coordinate access to GTK+. (They
are unnecessary if you are only making GTK+ calls from a single thread
thread.)

So, yes, making full use of these calls would be one way of approaching
the problem. (You'll want to read the threading section of the GTK+ 
FAQ and look at the example there.)

Another approach would be to figure out a way of communicating from
the second thread to the first thread and letting the first thread
do the work. You could use pipes, or you could take advantage 
of the fact that the GLib main loop is fully thread safe, do:

 g_idle_add (function_to_run_in_main_thread, data_for_function);

The first approach is preferable if the GUI work is heavily split
up between the threads, the second may be easier if you are mostly
doing GUI work in the main thread, but have one or two things you
want to trigger from the second thread.

Regards,
                                        Owen