----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, October 31, 2007 6:30 AM Subject: Re: Concurrent Futures
On 31/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/31/07, Rob Withers reefedjib@yahoo.com wrote:
I am trying to ensure that objects in one Vat don't get directly manipulated by objects in other Processes.
I don't see this part as too difficult, since you can't modify what you can't get a reference to. But the issue is mutable globals. The most obvious example here are class side variables: if multiple vats can see the same class and that class has class side variables that it mutates, then that's an issue.
This is not the only case. Its just a special case when two or more processing units having access to same mutable object. There are other problems related with reflective nature of smalltalk. A killer example is passing reference to context (thisContext) or stack to other vat/thread/processing units.
In both of these cases, the objects are owned by a particular Vat. Any messages to them from another Vat would be eventual. If they were passed to a different Vat (1->2) they would be VatRefs from 2 into 1. Anyway, this is the plan, it isn't working at this time.
A concern of mine is how well the development tools would work in a different Vat. So let's say we have the class browser open and we try to define a new class. The superclass is eventual, since it is owned by a different Vat. Where does the new class get created, in the current Vat or in the superclass' Vat? There are definitely issues here.