Re: Circular reference problem

[Nat Friedman <nat helixcode com>]

Maciej Stachowiak <mjs@eazel.com> writes:

> Nat Friedman <nat@helixcode.com> writes:
> 
> > There shouldn't be a circular ref loop.
> 
> I'm quite certain there is.

Right, I meant "shouldn't" as in moral imperative.

> > BonoboWidget holds a ref on the ControlFrame, which holds a ref on the
> > control, which holds a ref on its widget, and down the line.
> 
> BonoboWidget is not really relevant to my life in Nautilus, but even
> so this is not a complete view.

Right, but this is how widget trees work.  And I see no reason for it
to work differently in Bonobo.

> > The problem is basically that we need to make sure that the
> > ControlFrame unrefs the control before it goes away.
> 
> It does. But if you are trying to actually refcount the ControlFrame
> instead of doing esxplicit destroys, and the Control is still holding
> a ref, it will bever go away!

Do I have the word "stupid" written on my forehead?  I know this.  If
we are refcounting the control frame, I think this is a bug.

> > (I assume you are talking about Bonobo ref counts here, and not corba
> > object dups)
> > 
> 
> I am pretty certain the Control holds a ref on the ControlFrame and so
> there is in fact a circular ref loop. Are you suggesting this is a
> bug?  I actually think it is correct to hold a ref on the ControlFrame
> interface here, since the Control will feel free to make calls on it
> as long as I think it's live. 
> 
> So I think the bonobo_control_frame_unbind_from_control() solution I
> suggested is the best. As in other refcounted languages, you need a
> mechanism to break circular refs explicitly.  I will prepare a patch
> along these lines for the list's benefit.
> 
> See below for proof:

You're right, we are.  

The Control needs to be free to make calls on the ControlFrame, but
the ControlFrame also needs to be free to make calls on the Control.

Your solution seems ok, but I am still concerned about the destruction
semantics.

We need to think very carefully about this stuff, and have an answer
to each of the following situations:


    a. What does a graceful Control shutdown look like?  [ I imagine
       this is just the container unrefing the control ]

    b. What does a graceless Control shutdown look like?  If the
       Control dies spontaneously, how is the ControlFrame going to
       learn about this, and furthermore, how will it communicate this
       to the application code?  How does it avoid ever making calls
       on the now-dead Control interface?  What mechanism will lead to
       the eventual destruction of the ControlFrame object, which is
       now floating with a ref count of one?

    c. What does a graceful container shutdown look like?  [ I imagine
       this is once again all the controls being unrefed and then the
       container nuking itself. ]

    d. What does a graceless container shutdown look like?  This is
       a particularly onerous problem due to X and Gtk sucking.  I
       don't even want to go there anymore.  Once bitten and all that.
       I will be happy to lend my advice to whoever wants to own this
       problem, however.  It just sucks that I spent several days last
       summer on a Gtk patch to fix this stuff and it never got
       included properly.

Regards,
Nat