Re: Circular reference problem

[Maciej Stachowiak <mjs eazel com>]

Nat Friedman <nat@helixcode.com> writes:

> 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.

My apologies, I read it as "I don't think that is the case."
 
> Right, but this is how widget trees work.  And I see no reason for it
> to work differently in Bonobo.

Well, a widget has a way to be notified when its parent goes away
other than just the unref, so it knows it should not do operations on
the parent any more. In Bonobo, the
 

> 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:
> 

Let me take a crack at answering some of them.
 
>     a. What does a graceful Control shutdown look like?  [ I imagine
>        this is just the container unrefing the control ]

In the normal case, the container code unbinds the Control from the
ControlFrame, and drops any other refs it may have on the Control
object. It also drops any refs on the Control object. The unbind
breaks the circular reference, so both objects are freed if these are
the last refs.

>     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?

When the ControlFrame detects that the control has died, it should
cheat and unref itself. This may be a bad way to do things; it is
remotely possible that while the ControlFrame cannot talk to the
Control any more, the Control can still talk to the ControlFrame. Then
the Control might still unref the ControlFrame later, so two refs will
be lost when only one should have been.

>     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. ]

The container would do whatever it does to clean up each control and
then exit.

>     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.

Well, if you can survive X and Gtk killing you, it should be similar
to a graceless Control shutdown; at some point you detect that the
ControlFrame object is not responding so you unref yourself.

 - Maciej