Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 29 Jul 2010 15:00:53 +0200
Murray Cumming <murrayc murrayc com> wrote:
> On Thu, 2010-07-29 at 08:48 -0400, Paul Davis wrote:
> > But this libsigc++ issue is still an issue with gtkmm, right?
> > 
> > well, only if you try to use multiple threads that execute gtkmm
> > code. if you stick to the "all GUI (gtkmm) code is in one thread",
> > then there's no issue at all. i think the problem is that some
> > people:
> > 
> >      a) don't like that programming model
> 
> But then they are on their own, and I guess that libsigc++ won't be
> the end of their problems. They should do what we (and GTK+)
> recommend.
> 
> This thread started with "significantly affect the usefulness of the
> C++ bindings", which now doesn't seem so true.
> 
> >      b) want to use sigc++ for things other than interacting with
> > gtkmm and involving multiple threads
> > 
> > my answer to both is "don't". 
> 
> Well, I'm not against fixing libsigc++ in general. It is hard to
> depend on boost. But I don't feel that it's essential to fix these
> for gtkmm.

I am not particularly fussed about point a).  But point b) does seem to
me to make libsigc++ unsuitable for use in multi-threaded programs,
which is quite a lack of suitability these days in times of multi-core
processors and threaded programming.  It is highly likely that many
multi-threaded programs that uses sigc::trackable are not in fact thread
safe, perhaps unbeknown to the author, because the consequences of
trackable's lack of thread safety are so counter-intuitive.

Because of sigc::trackable even a) and b) are not complete.  For
example, you cannot start a thread in glibmm representing a non-static
method of an object deriving from trackable, irrespective of whether
you only intend to use sigc++ signals in the GUI thread.  The lack of
thread safety also makes Glib::Dispatcher less useful than it might
otherwise be (the only thing you can do to a Dispatcher in the thread
other than the one the Dispatcher was constructed in is emit() on it;
another thread cannot, for example, make connections to the Dispatcher,
or block them).

Chris