Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 28 Jul 2010 22:17:27 +0200
Krzysztof Kosiński <tweenk pl gmail com> wrote:
> W dniu 28 lipca 2010 17:49 użytkownik Chris Vine
> <chris cvine freeserve co uk> napisał:
> > 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.
> 
> This is OK in principle, but it would mean making sigc::trackable a
> template. Since many other types also derive from sigc::trackable, we
> need a way of specifying the mutex type of e.g. sigc::signal without
> adding an extra template parameter to it. How to solve this without
> using #define?

As far as I recall, signals do not know about sigc::trackable.  However,
slot generation in sigc::mem_fun() and helpers does have to, for two
reasons.

This is first because slot_rep derives from trackable: however, if we
are only aiming to deal with thread safety for remote trackables (the
case where nasty thread safety issues arise), then no mutex for this
internal trackable may be required (this would need to be analysed) and
if so sigc::mem_fun() will not need a further template paramater.

The second reason is that slot generation needs to deal with remote
trackables (that is to say, a case where the remote object is derived
from trackable) in order to determine whether to register a nulling
callback with with it, for which see sigc++/type_traits.h (to determine
base class relationships, if any) and sigc++/visit_each.h (to act on
it). I don't know if templatising trackable would affect these - I don't
really know enough about template meta-programming to be sure - but I
would guess that they would be affected.

If you wanted to make signals thread safe then they will also need to
be templatised on a mutex type, which would introduce additional
complications, but maybe it is best to deal with one task at a time.

Chris