On 24/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 10/24/07, Igor Stasenko <siguctua at 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.

-- 
Best regards,
Igor Stasenko AKA sig.