Re: gtkmm 3.0 and libsigc++

[Murray Cumming <murrayc murrayc com>]

On Wed, 2010-07-28 at 16:49 +0100, Chris Vine wrote:
> On Wed, 28 Jul 2010 15:27:07 +0200
> Murray Cumming <murrayc murrayc com> wrote:
> [snip]
> > > A signal/slot interface does not feature in C++0x.  If one were to
> > > be introduced into C++-1x, presumably it would be based on
> > > boost::signal2, which does not have these problems as it has been
> > > designed to be thread safe (and trackability is implemented
> > > differently).
> > 
> > So isn't it instead just time to think about using a (copy of)
> > boost::signal2 instead of libsigc++?
>  
> I think there has been discussion previously about importing things
> from boost, such as smart pointers.  The problem with using individual
> boost modules is that something like signal2 would bring in other parts
> of boost with it.  Those parts will be somewhat reduced once C++-0x is
> out, because presumably some of its threading and smart pointer stuff
> will be retired, but it would still be a significant import.
> 
> It would be better I suspect to fix libsigc++, which probably means
> redesigning trackability, which I don't believe the sigc++ maintainer
> is interested 

I'm probably the maintainer right now. I'm not against it if I can
understand it.

>   It would be a significant task and I hope
> Krzysztof is willing to take it on.  When I deal with threads I like to
> do things in small chunks where everything is as self-explanatory as
> possible and side effects are minimised: one of the problems with highly
> complex code like libsigc++, which does a lot behind the scenes, is
> that just carrying enough in your mind to be satisfied about things
> like thread safety or exception safety becomes extremely difficult.
> Until I pointed out the difficulties with sigc::trackable some years
> ago (I posted a couple of bug reports), even the glibmm threading
> examples in the tarball were not in fact thread safe, though they had
> been written by a very competent programmer.
> 
> If it helps, the way signal2 deals with locking is that it uses by
> default boost mutexes, but if a user has a single threaded program (or
> is using signal2 in a way which does not raise thread safety issues), a
> user can specify boost::signals2::dummy_mutex as the relevant template
> parameter type which makes all mutex operations a no-op.  If a similar
> approach were taken to libsigc++ that might keep everyone happy, and
> the default could be reversed for libsigc++.  That is, by default it is
> not thread safe and has no glib dependency; but it has a thread safe
> option which does have that dependency in any case where C++-0x
> mutexes are not available.
> 
> signal2 also makes extensive use of boost::shared_ptr to control object
> lifetime in an effort to maximise thread safety: in particular, an
> object which has automatic trackability must be constructed on free
> store and managed by shared_ptr if it might be destroyed concurrently
> by one thread as another thread invokes one of its methods via a
> signal, although I do not suggest we go down that route. To that extent
> I think signal2 goes too far, and because of object dependencies their
> solution can never be completely effective anyway. Documenting what is
> and what is not thread safe (which I would be happy to do) can be just
> as useful.  So far as concerns libsigc++ as currently designed, a post
> of mine a year or so ago set out how to program safely with libsigc++
> at some length: but it goes too far the other way. sigc::trackable is
> grossly unsafe (in my view).
> 
> Chris
> 
> 

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com