Re: [gtkmm] threads

[Drew Hess <dhess ilm com>]

Thanks to Christer and Martin for their reponses.  My post didn't hit the
mailing list for several hours because I'm not subscribed to the list, so
I just forged ahead with the simple Glib::Dispatcher code and came to the
same conclusions as Christer, and everything appears to be working just
fine.

SigCX does look interesting and I may end up using it for its portable 
semaphore support, amongst other things.

thanks again

-dwh-


On Tue, 14 Oct 2003, Christer Palm wrote:

> 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
> 
>