Re: gtkmm 3.0.
- From: Chris Vine <chris cvine freeserve co uk>
- To: Paul Davis <paul linuxaudiosystems com>
- Cc: Murray Cumming <murrayc murrayc com>, gtkmm-list gnome org
- Subject: Re: gtkmm 3.0.
- Date: Fri, 26 Mar 2010 21:45:37 +0000
On Fri, 26 Mar 2010 17:09:34 -0400
Paul Davis <paul linuxaudiosystems com> wrote:
> 2010/3/25 Krzysztof Kosiński <tweenk pl gmail com>:
>
> > I think sigc::trackable should have protected virtual functions for
> > its slot management operations, so that gtkmm can override them to
> > implement thread safety using GMutex; this would avoid adding a
> > dependency on Glib or Boost to libsigc++.
>
> i think its worth considering the words of the boost::signals2 people
> on this matter. signals2 has a much nicer, safer and more easily
> thread-safe model for managing connections. they still provide a
> "trackable" base class but its use is deprecated since they could find
> no way to make it acceptably efficient & thread-safe.
>
> i recently converted the entire backend of ardour from sigc++ signals
> to boost::signals2, and in general i find the signals2 connection
> management model MUCH more satisfactory.
I agree that the libsigc++ model is unsound in a multi-threaded
environment, but while gtkmm depends on libsigc++ I think it would be
desirable to deal with the most egregious problem with it, which is
that only one thread can safely construct slots representing ANY member
of a class derived from sigc::trackable.
Chris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]