Peter William Lount wrote:
> Jason Johnson wrote:
>> On 10/21/07, Peter William Lount <peter at smalltalk.org> wrote:
>>   
>>> tim Rowledge wrote:
>>>
>>> Ok, so if you really are talking about a "strict" Erlang style model
>>> with ONE Smalltalk process per "image" space (whether or not they are in
>>> one protected memory space or many protected memory spaces) where
>>> objects are not shared with any other threads except by copying them
>>> over the "serialization wire" or by "reference" then I get what you are
>>> talking about.
>>>     
>>
>> That is a strange way of putting it.  
> 
> Why? That is what Erlang achieves via it's total encapsulation of state 
> that is only transferred by message passing to and back from a process. 
> To achieve the same thing in Smalltalk you'd need to isolate the 
> component objects running in an "image" object space with the process 
> otherwise you'd be breaking the encapsulation that provides the 
> protection against a large number of class es of concurrency problems.
[more stuff snipped]

Hello all,
I think that Erlang does have mechanisms to share
stuff between processes. First, the code is shared.
When I update a module, all processes using the
code of the module will (eventually) switch to the
new version.
And then there is the Mnesia database and its parts
that can be used to share data between processes.

And, slightly off topic probably:
One thing that strikes me as remarkable about the
Erlang system is that, since there is non-destructive
assignment, you cannot have cycles in your object
graphs. I think this simplifies the GC tremendously.
But I can think of no way of doing something similar
with Smalltalk objects, unfortunately.

Cheers,
Wolfgang