Recent Features
| |||||||||||||
Managing GNOME shell extensionsManaging GNOME shell extensionsPosted Sep 23, 2011 16:59 UTC (Fri) by otaylor (subscriber, #4190)In reply to: Managing GNOME shell extensions by ebassi Parent article: Managing GNOME shell extensions
Actually, it's not just some implementation limitation we decided on. We simply don't know any way to have an object shared by three different garbage collection systems, work right, and not be leaked. (This is under a fairly strict definition of "work right" ... including among other things that the proxy object are persistent - that I can say in Python button.some_property = 5 and that's there even if the last Python reference to the button is dropped, then you get the object back by traversing the widget graph.)
(Log in to post comments)
Managing GNOME shell extensions Posted Sep 24, 2011 12:21 UTC (Sat) by nix (subscriber, #2304) [Link]
Yeah, the only ways to make this work right are
1) maintain a copy of the object inside the separate VMs. This rarely works unless the object has no mutable state (e.g. results of queries).
2) maintain a reference to the object in a proxy, while the object itself remains in C space, not managed by any of the GC systems. If you want a weak link to the C-space object, so the C universe can delete it regardless of the VM's references, you need another layer: a proxy in GCed space pointing to a proxy in C space which then points to the object itself, which ensures that when the C-space object is deleted, you can reseat the C-space proxy to point to a singleton null 'deleted' object, which the VM-resident proxy objects can then use to detect said deletion.
It's far too much work to have the GC systems cooperate, but you can certainly have them stay out of each others' way (and this has been done before, often).
|
|||||||||||||