Re: Introducing "toggle references"

[Alexander Larsson <alexl redhat com>]

On Mon, 2005-04-25 at 22:18 -0400, Owen Taylor wrote:
> On Tue, 2005-04-26 at 02:01 +0200, Tim Janik wrote:
> > >
> > > In terms of the overall scheme, the main problem that I know
> > > with it is that it can't handle the case of two language
> > > bindings referring to the same object:
> > >
> > >        Language Runtime A                Language Runtime B
> > >                            |           |
> > >                            |           |
> > >                    Proxy <--- GObject ---> Proxy
> > >                           --->        <---
> > >                            |           |
> > >
> > > Is still uncollectable.
> > 
> > so then, why not introduce add_/remove_ proxy_link (or proxy_ref) then,
> > which notifies on the transition
> > ref_count>n_proxy_links => ref_count=n_proxy_links ?
> > 
> > objects kept alive purely by proxy links shouldn't be interesting
> > to language bindings, so they can drop their proxies with ref_count==1.
> 
> I had that thought, but it doesn't work out ... GObjects kept alive
> only by proxy links *are* interesting. In a situation like:
> 
>         Language Runtime A                Language Runtime B
>                             |           |
>                             |           |
>  Other object --> Proxy A <--- GObject ---> Proxy B
>                            --->        <---
> 
> If we weaken the references from the GObject to the proxies, then
> Proxy B will be collected prematurely.

Is this such a huge problem though? In this case we'll collect B
prematurely in this case. But this is what the current solution that
Gtk# uses does in this case, and that doesn't seem to hugely impact Gtk#
users. 

With your proposal you would instead never be able to collect either of
the proxies or the GObject. They will be leaked forever. Loosing the
proxy data is only a problem if we somehow get a reference to the object
in Runtime B, which is unlikely given that the only reference to the
object is in Runtime A (but its not impossible).

So, it would cause slight problems working with two runtimes, but it
will correctly manage memory. And if you're careful you can avoid the
possible problems.

On the other hand, maybe leaking such shared objects isn't a huge
problem. I mean, if you're already using two language runtimes, whats a
few objects more or less...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a scarfaced overambitious boxer with a secret. She's a tortured hip-hop 
mermaid from aristocratic European stock. They fight crime!