Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 27 Jul 2010 16:51:52 +0200
Krzysztof Kosiński <tweenk pl gmail com> wrote:
> W dniu 27 lipca 2010 11:01 użytkownik Murray Cumming
> <murrayc murrayc com> napisał:
> >> 1. sigc::trackable is not threadsafe.
> >
> > A patch for this could make a break far more likely. I wouldn't
> > want to do 2 breaks.
> 
> The easiest way to fix this is to allow sigc++ to depend on Glib when
> it's present at build time. In addition to being able to use Glib
> mutexes, we could use the slice allocator. Since the predominant use
> of libsigc++ is within gtkmm, this would not add an extra dependency
> in 95% of cases, and in the remaining 5% it could be turned off at
> build time. Is this OK?

When I was looking at this, I did some thinking about whether, by
analogy with the std::queue container type, the slot container type for
sigc::trackable (which is at present a std::list object) could be
specified as a template type.  In that way you could have std::list as
the default, but also enable a user to specify a thread safe container
type in its place when needed.

In the end I think I concluded that a thread safe implementation doing
it this way would be extremely difficult to achieve, for a reason I
can't now remember.  (I also ended up with the view that retaining
trackability as a property of the object whose methods the slots
represent, rather than a property of a signal connection, was also
difficult to achieve in a thread safe way.)  However, if you are
planning on fixing sigc::trackable it may be worth looking at the
templated container type approach.

Chris