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.

Another alternative would be to introduce an immutable flag on
references, then the "receiver" gets a reference to the object but
flagged immutable.  This way might be better, but requires more
changes.

> Its unclear how you would determine to which process object belongs
> to? This is at minimum would require an additional slot per object
> (ok, this is doable easily).

Not needed.  The boundaries are: object creation, object send and
object receive.  All controlled from the VM or in the library, so I
just have to guarantee that a mutable object can never sneak out of
it's process, i.e. a process can never get a mutable reference to an
object owned by a different process.

> Also, unclear how you would persist state (or results of computation).
> Since all you can do now is to send a message to process, which will
> return an object in answer.

No, all message sends are async, fire-and-forget.  You don't get a
future or anything back.  You can easily build sync messages on top of
this if you want, but the base system isn't planned to directly
support it.

> Now, since returned object most probably
> will belong to callee process you must copy it to caller process. But
> in real you should care of copying a whole subgraph of objects (since
> you can return a collection of newly created objects (and they , in
> own turn can be a collections e.t.c.)- and all belonging to callee
> process). Then , after you done merging a graph, you can simply wipe
> all memory which was allocated by callee process. This part is easy.

Ah, if you're talking about the receive call, yes that will get an
object returned.  My first cut will just be (as mentioned above) a
deep copy.  Performance will likely drive me to adding immutable
references, or objects or something.  Or perhaps what you're
suggestion here.

> Now, the most interesting part: mutating an objects in caller process.
> Suppose my starting process calls two different processes.
> And they came to the point, that they are willing to update a state of
> some object(s) in caller process (to be clear: process A contains
> object a, it calls processes B and C in parallel, and now B and C
> wanting to change state of object a).

Can't happen.  There is no shared state.  Ever.  The only thing that's
shared is the Process' mail box, but that is an internal VM detail,
not visible to the processes.

(remaining comments snipped since I think they assume shared state
which does not exist in my plan.  If you have some reason you think I
can't avoid it let me know because I don't see it so far).