On 14 October 2012 01:31, Levente Uzonyi <leves at elte.hu> wrote:
> 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).

In Erlang you can get away with this because of its ubiquitous
immutability. But removing all concurrency from an image means that
you can _today_ (without waiting for the VM support, in other words)
start doing share-nothing message passing concurrency.

It might be cheaper computing-wise to use green threads, but for us it
might be (MUCH) easier to pay the computing cost of multiple images
than trying to make things in the image immutable.

For instance, Point is perfectly safe to share - mutating methods
return new Points - but you can't share an Array without the mere
convention of copy-before-changing. Even if one uses persistent data
structures (something both Levente and I have done), you still have to
rely on people not violating the contract of the structures (by
exploiting a bug in the data structures, by breaking encapsulation
through #instVarAt:put:, ...). And the cost of this violation is dear:
random stuff breaks for no apparent reason.

frank

> Levente
>
>>
>> Colin
>>
>
>
>