Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

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