goran.krampe at bluefish.se wrote:
> Hi folks!
> 
> John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> [SNIP]
> 
>>think interesting things would happen. An easier solution as Tim points  
>>out is to run 2 or 5 or 1000 images and distribute/share data via  
>>sockets or even shared memory. I recall once hearing about a Gemstone  
>>solution that used shared memory, to enable the sharing of mostly  
>>static data 100MB+ across lots of images. That reduced the overall  
>>footprint on the server by lots.
> 
> 
> 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)

> 
> 
> regards, Göran


-- 
skype: matej_kosik
   icq: 300133844
  http://altair.dcs.elf.stuba.sk/wiki/Main/MatejKosik
phone: (421) 910-993-245

-=x=-
Skontrolované antivírovým programom NOD32