Re: gtkmm 3.0 and libsigc++
- From: Paul Davis <paul linuxaudiosystems com>
- To: Chris Vine <chris cvine freeserve co uk>
- Cc: Murray Cumming <murrayc murrayc com>, gtkmm-list <gtkmm-list gnome org>
- Subject: Re: gtkmm 3.0 and libsigc++
- Date: Thu, 29 Jul 2010 08:37:48 -0400
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]