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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part