Re: Threads and gtkmm

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 29 Mar 2011 14:44:00 +0200
Yann Leydier <yann leydier info> wrote:
> > Yann Leydier<yann leydier info>  wrote:
> >> Thanks for the info. I was still using g_idle_connect with static
> >> methods to communicate between threads…
> >
> > I assume you mean g_idle_add(), and that's a perfectly good way to
> > do it, and is thread safe, but you forfeit trackability.  (Although
> > if you are passing static class member functions to the callback
> > argument of g_idle_add() you technically have undefined behaviour
> > because static member functions have C++ linkage specification and
> > not C linkage. However, it will work OK with gcc, and glibmm does
> > it, so you are not adding any greater unportability.)
> 
> Yeah, sorry, I mistyped the name !
> 
> It works with GCC and seems to work also as well with Visual Studio
> 2008.

It does, yes.  As far as I am aware it is only some Intel compilers
which use a different calling convention for static member functions
with c++ linkage than functions with c linkage, where you will hit
problems. I am not sure about the sun compilers though.

> > The first won't work because Dispatchers can't be copied (this is a
> > feature not a bug).  The second is not desirable because passing
> > around Dispatchers by pointer is likely to leave your code with
> > dangling pointers.
> > If a Dispatcher is a class member, why not provide an accessor
> > function, or make it a public member?  These would be the normal
> > ways of doing it (as with sigc::signal objects).
> 
> I'd rather not use an accessor to improve genericity of the object 
> recieving the Dispatcher. I think I'll use shared (and perhaps weak) 
> pointers.

If you are sharing ownership, be aware that the Glib::Dispatcher object
must remain in existence after an emission is made on it until the
connected slots have executed in the glib main loop for that emission:
otherwise a call will be made in the main loop on a non-existent
sigc::signal object. (Unfortunately no check for the continued
existence of the relevant Dispatcher object is made when the main loop
executes emit() on the Dispatcher's signal object - it is for the
user to provide her own synchronisation where necessary.)

Chris