On Sat, 13 Oct 2012, Colin Putney wrote:

> On Sat, Oct 13, 2012 at 2:02 PM, Chris Cunnington
> <smalltalktelevision at gmail.com> wrote:
>
>> I'm not sure I caught it myself. Something about a single process vm, but I
>> thought the vm was already single process. Then I sort of got the idea all
>> the processes in the ProcessBrowser would be gone and there would be one
>> process. This had to do with... I didn't get it, quite.
>
> That's right, there would only be one Process... or, ultimately, no
> Process class, but just thisContext and its senders. The idea would be
> to get rid of concurrency within the image, and replace it with many
> images executing concurrently and communicating with each other.
>
> This would be an improvement for several reasons:
>
> 1. We'd have parallelism as well as concurrency. Each image/vm would
> run in a separate OS process, and potentially on different processors,
> allowing us to make use of multiprocessor hardware.
>
> 2. Since each image would have its own object memory, there would be
> no shared state between images, and that would simplify the
> programming model. We'd still have to worry about coordination between
> images, but we'd never run into bugs because of state being changed
> when we weren't expecting it.
>
> 3. It would be a better fit for the kind of hardware that we seem to
> be moving towards—highly distributed systems without a single coherent
> address space.

This is similar to Erlang's process model, but there's one big difference. 
In Erlang every process is lightweight (not 1:1 mapped to OS processes), 
so there can be many of them, because they're cheap (just like in Squeak 
now).


Levente

>
> Colin
>
>