Recent Features
| |||||||||||||
Managing GNOME shell extensionsManaging GNOME shell extensionsPosted Sep 23, 2011 16:21 UTC (Fri) by ebassi (subscriber, #54855)In reply to: Managing GNOME shell extensions by nix Parent article: Managing GNOME shell extensions
What? Yes you can. I do it all the time.What? Yes you can. I do it all the time. you left out the important bit of my reply: GObject does not allow that. each language binding will have to keep a reference on the native C object, and get notification when the object goes away in the underlying library. GObject only allows one of those notifications because more than one would a) clash with the ABI guarantees (we don't have infinite space in the GObject structure and we cannot add fields without breaking the ABI) and b) would impose performance restrictions (suddenly, object destruction is O(n) with n being the number of "toggle" references). so, no: GObject does not allow multiple VMs with different GCs in the same process, and that won't change in the short term. you can get more information in this thread on desktop-devel-list.
(Log in to post comments)
Managing GNOME shell extensions Posted Sep 23, 2011 16:29 UTC (Fri) by nix (subscriber, #2304) [Link]
That... doesn't seem like the sort of fundamental restriction you were implying. It seems more like a 'we can only think of one way to write a VM' problem. Off the top of my head: it is perfectly possible to do all these things via some sort of central registry which takes the single allowed reference: you'd just need to have all the VMs load some package that cooperated with such a registry. Since the VMs would have to load at least one specialized package in any case (to be of any use as an embedded language), this problem is moot. There is no need for the VMs themselves to cooperate at all. All they need is an FFI that calls out to C and the ability to load modules written in C, which virtually every VM must have if it is to be of any real use.
Managing GNOME shell extensions Posted Sep 23, 2011 16:59 UTC (Fri) by otaylor (subscriber, #4190) [Link]
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.)
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).
|
|||||||||||||