[gtk-list] Re: Another thread over gtk api?

[Owen Taylor <owt1 cornell edu>]

Myslik Vladimir student 4_96_97 k336 <xmyslik@sun.felk.cvut.cz> writes:

> I just came around to the gtk library. Looks cool. I started to code the 
> frontend for my application that computes some scientific data. The 
> problem I'd like to ask is how to make my application compute data in 
> background, whilst the api works and displays the images computed as they 
> come? Can I use mere threads? is gtk library thread-safe? Or should I use 
> some IPC & shared memory mechanisms instead, thus having at least two 
> processes? I'd really wanted to have it this way, since the gtk stops 
> redrawing its windows when I call something to compute (it takes seconds to 
> compute 1 image, whereas I need a lot of them).

It's an interesting question. I think the simple answer is no,
gtk is nowhere close to thread safe. Putting a big lock around
the whole library would be pretty damn tedious since gtk/gdk
has approximately 780 entry points. If you were willing to guarantee
that two threads would never access widgets under the same 
toplevel, it wouldn't be too hard to lock the global data 
correctly (I think). If you just ensured that two threads never
accessed the same widget, you'd have to do some hacking on the
resizing code (which is pretty complicated), but its probably
a doable project.

On the other hand, in your case I would just confine all the code
that interacts with gtk to a single thread. Have the computational
thread write its data into a buffer and set a flag, and have
the interface thread check the flag in a timeout and redraw when
necessary.

Regards,
                                        Owen

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null