On 10/24/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> Sorry for spurious replies.. but.. this statement means that your
> processes are not so cheap as Erlang ones.

Why not?  At this point in time (afaik) they do the exact same thing
in all but one case (communication between 2 "green" processes in the
same image).

>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).

Yes, you can.  But this isn't the common case.

> 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.

Well, I have no plans of doing "futures".  Others are well down that
path, so no need for me to duplicate their research.  As far as
immutable references, all class have a header with various flags, I
would only need one more for mutability.  Such a change does scare me
a bit because the VM would have to be changed that all instVar sets do
an extra check, which would impact non-concurrent code as well, but if
it could turn out to be a good trade off vs. doing a deep copy every
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..

Bad example. :)  SmallInteger isn't mutable and isn't an object.

But I understand what you mean, the required traversals do sound
expensive, but this has to be done *every time* when you send between
two images anyway.  Lets not optimize prematurely. :)

> Honestly, i can't see how this concept can be considered cheap and scalable.

A system with 9 9's of reliability comes to mind. :)

http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3364027251

But really, as soon as you talk between two systems, no other approach
is better.  A "futures" concept can lazily load the data, saving time
when parts of a structure aren't used, but what are the numbers on
this?  How often do you send a message with a % of unused data high
enough to offset the complexity cost of the "futures" mechanism?

Yes, interprocess communication between two same-image process would
be a disadvantage, but I'm pretty sure Erlang started this way and
optimized from there.  That's my plan as well.

After all, we don't know how expensive this would actually be in
practice anyway.  It's easy to come up with theoretical examples that
cripple the system, but will anyone actually do this?  And if they do,
it will break and they can code around it.

Back before Unix, people were trying to figure out ways to ensure
resource deadlocks can not happen.  This theoretical problem
effectively crippled them from releasing a system.  Unix simply
ignored it.  They gave you tools to see you had a dead lock, and a way
to kill dead locked processes.  Seamed to work out for them. :)