Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 28 Jul 2010 18:33:31 +0200
Murray Cumming <murrayc murrayc com> wrote:
> 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.

There are four levels of thread safety to look at, in roughly ascending
order of difficulty:

1.  Make sigc::trackable thread safe.  This means that having
constructed one slot for an object deriving from trackable, you are not
then prohibited from constructed any other slots for non-static methods
of the object in another thread.

2.  Make sigc++ signals thread safe.  This means that once any one
thread has constructed and connected to a signal, any thread can emit
on it.  (The connected slots would of course execute in the thread
which emits, we are not talking about inter-thread communication here.)

3.  Make sigc::connection objects thread safe.  This means that if one
thread has constructed and connected to a signal, another thread can
block or disconnect the signal.  (Note: sigc::connection inherits from
sigc::trackable.)

4.  Make connected objects thread safe.  This means that you can emit
on a method of an object while another thread is trying to tear it down.

Of these, 1 seems to me to be essential, and 4 is self-indulgent, even
though boost::signal2 tries to do it (and it seems to me also to be
impossible because of object dependencies).

2 and 3 probably require a re-write and can't be done within gtk+-3
timescales. 1 above should be achievable within those timescales:
however, I looked at this and I found the sigc++ code very, very
difficult to tease out because of the way it is built [1]. If Krzysztof
could give it a try that would be great.

Chris

[1]  In the end, it was less effort to write my own
minimalist thread-safe signal/slot classes which do 1 to 3, which I
can use when I need them.