On Jan 19, 2005, at 8:58 AM, Matej Kosik wrote:

> goran.krampe at bluefish.se wrote:
>> GemStone has a VM plus a whole bunch of other processes running in a
>> shared-memory-pages-scheme with a transaction model keeping it all in
>> synch.
>> The net effect is that multiple VMs share (through transactional
>> replication) "an image" or what is often referred to as an object
>> memory. This means there is no "automatic" parallellism in actual
>> *computation* going on - I mean, you still have to turn your Smalltalk
>> code into multiple processes/threads - which your post also explained,
>> just wanted to stress it once more. But at least a multitude of VMs 
>> can
>> run (each on its own CPU and possibly own box) sharing the same object
>> space in a coordinated fashion.
>> This is of course also what Magma/GOODS etc can give you - a shared
>> transactional memory.
>> Given my limited knowledge in the area it seems that the semantics of
>> message passing would have to be changed in order to get "automatic 
>> full
>> scale" parallellism. Typically each object would execute in its own
>> Process and messages would be asynchronous. I also assume these lines 
>> of
>> thought is what SqueakELib
>> (http://map1.squeakfoundation.org/sm/packagebyname/squeakelib,
>> www.erights.org), Croquet in some way and also Tweak is experimenting
>> with.
>
> Concerning E I have come to the following conclusion:
>
> "E objects do not migrate (for security reasons). It makes it 
> unscalable. Also the existence of ''vat''-s is awful. It does not seem 
> to be suitable for fine-grained parallel computation because E's 
> constructs for asynchronous message passing are not powerful enough in 
> order for the programmer to be able to express everything solely by 
> means of them. Furthermore, the computation inside the ''vat''-s 
> happens in so called ''turns''. These turns cannot execute 
> concurrently because inside each turn programmers usually do normal 
> call/return-s and thus they would need to use additional 
> synchronization mechanisms on the shared mutable data.
>
> E seems to be a good platform for creating loosly coupled 
> (information) systems."
>
> (my personal opinion)

While E has a narrow focus on security, the concurrency model may be 
taken without the security/crypto design implications that go with it. 
In my case, I am working with such an option for Slate as a concurrent 
language extension, and eventually cryptographic security can be added 
as an optional transport layer. I also want to focus on Erlang-style 
signalling between processes, which goes a step further than broken 
promise resolution in E.

Of course, the E fellows aren't directly helpful with this kind of 
effort, simply because their whole focus is security and their example 
of E. It's difficult to bring up an issue with them and not get just 
the security slant, so I've had to work it out myself.

Also, from what I understand from following the Croquet and E projects, 
it seems that the interest from Croqueteers towards E has not seen a 
real follow-through, at least from the E perspective, so don't count on 
them to deliver a full solution to the integration issues. It's a tough 
task and requires a lot of focus.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/