Re: Introducing "toggle references"

On Wed, 2005-04-27 at 15:09 +0200, Alexander Larsson wrote:

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

It's not clear what the impact is on Gtk# users ... apparently people
do run into problems occasionally. I also think from reading the code
there are some leaks in Gtk# that may hide the problem at times. 

But if "Proxy" B were collected prematurely collected in the 
above graph it's actually a lot harder to work around then in
the single language case, where defensively holding pointers to
all your objects can hide the problem -- how do you document it:

 If you create a GObject implemented in C# and use it in a Java
 program, you must be sure that there is always a reference held
 to the C# object from the C# runtime.

How does the Java programmer do that?

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

The word "Proxy" here is somewhat misleading ... the Proxy may actually
be the real implementation of the object, or at least have data that
is essential to handling signal handlers connected to the object.

If the language runtime has other mechanisms (like Python, Perl) for
dealing with the circular GObject <--> language reference, it should
use them instead of toggle references.

If the language runtime can detect that the proxy is a "pure" proxy
and has no state attached to it, then it should use a weak reference
instead of a toggle reference.

So, I think we can reduce the leak case to situations such as:

 - A non-Widget GObject is created in Java, and signal handlers 
   attached to it.

 - The object is passed to C#, and more signal handlers are attached.

 - All other references are dropped

If you have such a situation *and* you are creating such objects
in a loop, then you'll need to do a workaround like calling 
dispose() on the object to remove all signal handlers.

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

It's not clear to me how you avoid the inadvertent free

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

In the end, I'd rather have leaks then objects unexpectedly being
collected leading to crashes. Though neither is good.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]