Re: [gtkmm] threads

[Christer Palm <palm nogui se>]

Hi Drew!
I have almost exactly the same situation in the app I'm working on 
(putting a gtkmm UI on top of a preexisting multithreaded core, which 
knows nothing about Glib or gtkmm, and shouldn't do so).

Drew Hess wrote:
> 1. Currently, the Scene thread is the only thread that'll be invoking the 
> Dispatcher, i.e., it's the only sender thread.  There's only one GtkViewer 
> object and it is single-threaded.  Do I need to call Glib::thread_init in 
> the GtkViewer?

AFAICT, no. You shouldn't need to call Glib::tread_init() at all if you 
don't use any Glib thread functionality, and Glib::Dispatcher is 
strictly speaking not part of Glib's thread system as it works with a 
pipe. At least I don't do it and it works for me.

> 2. Is it safe for the Scene thread to invoke the Glib::Dispatcher via the 
> GtkViewer::notify method, even though that Scene thread doesn't make any 
> other Glib calls?

Yes. As far as you don't do any other fancy stuff in the notify method, 
that is.

> 3. Assuming that at some point in the future I create multiple Scene 
> threads, each of which want to send "copy" messages to the single-threaded 
> GtkViewer, do I need to put a lock around the Dispatcher in the 
> GtkViewer::notify method?

No, you should be able to call the Dispatcher from any context without 
any special precausions.

>  From the Glib::Dispatcher documentation page, 
> it sounds like not, but it's not clear to me whether that assumes that 
> each sender thread has its own instance of a Dispatcher.  In the scenario 
> I'm describing, there is only one Dispatcher object, and it belongs to the 
> single GtkViewer object.

The only locking you need to do explicitly in this scenario is on any 
data shared by the threads. I suppose the Scene puts the image to be 
rendered into some buffer which is picked up by the Viewer, for example. 
There is no guarantee as to when the signal will actually be delivered 
to the Viewer thread, so you have to make sure that the Scene stays away 
from the buffer until the View has actually picked it up.

SigCX (optionally) provides synchronous signals which is a simple way to 
avoid locking issues in many cases. It also adds the ability to pass 
arguments to cross-thread signals, which can be another easy way to 
avoid locking issues.

I had a tough time with the SigCX examples at first, because there is no 
trivial example, but once you understand the mechanism its not much 
different from Glib::Dispatcher, but much more powerful. I can highly 
recommend it.

--
Christer Palm