Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 12:35:40 -0400
Paul Davis <paul linuxaudiosystems com> wrote:
> i prefer the boost syntax for this:
> 
>     boost::weak_ptr<Foo> weak_foo = ....;
>     ...
>     [ // scope begins for use of referenced object ...
>            boost::shared_ptr<Foo> shared_foo = weak_foo.lock ();
>            if (shared_foo) {
>                 ... use shared_foo to access object ....
>            }
>     ] // scope ends
> 
> although its clearly semantically equivalent. in your example, you've
> changed the nature of s from a weak reference to a strong reference.
> if it wasn't scoped, that could cause some odd side effects. either s
> is or is not a weak reference, preferably.

I had done that indeed, in order to make thread safety optional.  You
will see my reply to Jonathon Jongsma, who has put this code into
"Glib-speak" and why I think thread safety is much more difficult than
I first thought, because of the way GObject finalization works.

I now prefer to go back to my most original proposal of not bothering
with thread safety given that gtkmm widgets are not thread safe anyway,
so that a simple 'if' test on the validity of the weak pointer will do
fine, in the same way as you would with g_object_add_weak_pointer().

> as i've mentioned to daniel on IRC, it would make our life in ardour
> MUCH easier if all gtkmm objects were reference counted with both weak
> and strong references available. we have a very nasty and hard to deal
> with situation right now where we schedule a callback on a GUI object
> from a non-GUI thread, and by the time the callback is executed, the
> GUI object has been deleted.

Two approaches come to mind: using g_object_add_weak_pointer() on the
underlying C object.  Or using a Dispatcher object with a slot
representing a method of the GUI object which is protected by
sigc::trackable.  (That will work provided all slots representing
methods of the object are constructed in the GUI thread.)

Chris