| |||||||||||||
Managing GNOME shell extensionsManaging GNOME shell extensionsPosted Sep 23, 2011 9:05 UTC (Fri) by ebassi (subscriber, #54855)In reply to: Managing GNOME shell extensions by debacle Parent article: Managing GNOME shell extensions
I'm sure, it's only matter of short time, until somebody implements Python or other languages support for the GNOME shell. no, you cannot mix different virtual machines with different garbage collectors within the same process. GObject simply does not support this because it's insane. if extensions were to be executed out of process then you would not be able to monkey patch internals, so there are various trade-offs to consider.
(Log in to post comments)
Managing GNOME shell extensions Posted Sep 23, 2011 11:02 UTC (Fri) by nix (subscriber, #2304) [Link] no, you cannot mix different virtual machines with different garbage collectors within the same process.What? Yes you can. I do it all the time. Lots and lots of processes link against both libpython and libperl, which have their own independent virtual machines with their own different GCs. There are even bridges permitting e.g. Python and Lua to talk to each other (both VMs with their own independent GCs). What you have to do is ensure that no piece of data ever ends up traversed by more than one GC, which just means designing the FFI right. (Lua's is designed right for this: I don't know about other languages.)
Managing GNOME shell extensions Posted Sep 23, 2011 16:21 UTC (Fri) by ebassi (subscriber, #54855) [Link] 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.
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).
|
|||||||||||||