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.
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).
No sharing you say? Oh.. don't let me starting on this. How about a common procedure of creating a new class? Creating or modifying a method in some class? Note that these changes propagated globally in current implementation due to having a single global namespace (SystemDictionary). How you planning to deal with that without breaking a uniform model of smalltalk (everything is an object e.t.c)?