Re: gtkmm 3.0 and libsigc++

[Paul Davis <paul linuxaudiosystems com>]

2010/7/29 Chris Vine <chris cvine freeserve co uk>:
> On Thu, 29 Jul 2010 01:45:04 +0100
> Chris Vine <chris cvine freeserve co uk> wrote:
> [snip]
>> But, as I say, it is the thread safety of remote trackable objects
>> which seems to me to be the more pressing point.
>
> The gory details of my conclusions when I last looked at this are
> coming back to me, and as you have probably by now concluded it is not
> as simple as that.
>
> When the destructor of a remote object deriving from trackable nulls
> any slots referring to its methods, those slots will be nulled in the
> thread in which the destructor executes, which may not be the thread
> which "owns" a particular signal object which might emit on the slot.
> If and when that other thread does emit, the slot may (as far as its
> memory visibility is concerned) be in an inconsistent state.  The
> problem would be even worse if the remote trackable not only nulls the
> slots, but also removes them from the signal object (I cannot now
> recall whether it does that or not, but I suspect that it does).
>
> So in practice it is probably impossible to make trackable meaningfully
> thread safe without also making signals and connection objects thread
> safe.

that was my conclusion when i did a fairly in-depth investigation of
both sigc++ and boost::signals2

my eventual decision for ardour3, which was suffering some
increasingly critical problems from the using of sigc++ was relatively
simple:

   * continue to use sigc++ for all connections to gtkmm signals,
since all gtkmm code executes serially in 1 thread
   * drop the use of sigc++ for anything unrelated to gtkmm, and use
boost::signals2 there, along with a "wrapper" class that
         imposes properly scoped connections to replace inheritance
from "trackable" and one other semantic nicety
         that in sigc++ is also handled by "trackable".

the result has been fairly satisfactory, although i would say that the
connection syntax is a little bit unwieldy now:

	_route->processors_changed.connect (*this, invalidator (*this),
ui_bind (&MidiTimeAxisView::processors_changed, this, _1),
gui_context());

there is some rather "clever" stuff going on in the ui_bind() call
which i can explain if anybody really wants to know. the final
argument (gui_context()) is a glib main loop where the functor created
by ui_bind() will execute.

but to stress again: the key decision was to just leave sigc++ alone
in connection with gtkmm, which was easy for us since we already use
the "no GUI code in another thread" model.