On 24/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/24/07, Igor Stasenko siguctua@gmail.com wrote:
Aha, now i get it.
Good, I should have just posted some theoritical Smalltalk code to begin with, this thread would probably be half as big. :)
So, your approach is to establish a fence between different processes, so they can't share objects. Or maybe more correct to say, that any callee process can have read-only access to any objects which belongs to caller process?
No, the plan was that since in Smalltalk objects are mutable, I will have to pay an extra cost for internal message sends and have the VM do a deep copy for the sent objects.
Sorry for spurious replies.. but.. this statement means that your processes are not so cheap as Erlang ones. By passing a single object to new process you could trigger a cloning a substantial part of image in this case (read - megabytes of data). Or even if not cloning, then marking objects as read-only, or creating a 'hollow' references to objects, which is too have own costs - extra space and access time. Even for spawning a process which doing no more than adding 1+1 i need to copy/mark a SmallInteger class and all its references, until i mark everything reachable from it.. Honestly, i can't see how this concept can be considered cheap and scalable.