Hi there, I'm following this discussion with great interest,

	after introducing myself in what Eralang is by reading
http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html
referenced by Igor, I have a question (that maybe is silly I don't know
that's why it's a question after all :)

	Some contextualization first:

	1. Speculative by analogy: 

	1.1 Casually about a month ago I've attended a seminar of a
neurologist that explained he's research and proposal about a new and more
complete theory of dreams. What I've learned there and I'm associating with
this regard is the concept of tides, very common for neurologists by the
way. They talk about tides of zillion of impulses in the brain cells
interconections triggered by senses or even thoughts, emotions, etc. 

	1.2 the interpretation of (1) Objects as conceptacles in the sense
of a receptacle of a concept: "definition of behavior and/or a holder of
memory of another/s conceptacle/s" and interpretation of (2) that something
trigger a tide which is composed of lots of little impulses.

	1.3 this huge quantity of impulses are like well organized little
messages that have no problem at all to work concurrently. 

	1.4 I'm interpreting the normal thousands of processes Erlang
manages as analogue (so similar in function) to one of this tides and point
why we cannot make tides of Smalltalk message sends in an image?
 
	2. Erlang made it's point in theory about making paralellism really
scalable. Then made it's point materializing it into enough succes stories
to focus interest of people with pragmatic/con$ervative profiles. The
hardware trend indicates this will be of great value.

	3. If I understood well, Erlang's main strenght is not that it has
functions to do things but that it has a message passing technique really
great that was designed to take advantage of parallelism in a simple way
efficiently and making processes very cheap (ceaper than the OS ones).

	4. If I recall correctly (please correct me if I'm wrong) in "The
Computer Revolution hasn't happend yet. Keynote OOPSLA 1997" Alan Kay says
that object oriented was not the most happy way of calling OOP becaouse
after the initial happines of focusing thought in objects happens to become
of a higher priority to think about the process of that objects. This is,
not the "body" they have but the "lives" they live with it. So.. he also
said that may be process oriented could be a better way to call it todays.
Making it's point about the importance of message passing and continues he's
talk.

	Said that and that I don't have experience with VM internals nor
Erlang in an exercise of imagination naively I ask:

	The intersticial space of virtual objects, AKA messages sends, can
be "Erlanged" by making each message send to be in a "process" (the cheap
ones) of it's own like Erlang messages between "process"?

	Same in other words:

	What consequences will affect us if we make a Squeak to use a VM
that to pass messages use processes ala Erlang (that are simple, cheap,
efficient and scalable in a world of "cores")?

	Can this allow us to assimilate in the Smalltalk's objects paradigm
the Erlagn's process paradigm? This is: will this allow us to gain that
parallelizing benefits preventing us to change the programing paradigm?

	If I understood well this will be (an unknown quantity?) change in
the message passing part of the VM and probably has an impact on how todays
an image understood what aProcess is to become what it allways should be by
giving to processes the importance that they allways deserved and hardware
technology wasn't able to deliver (deviating the focus of sofware developers
due to sad hardware limitations) to them until todays (in an economy of
scale way, AKA cheap). So every message send *is* in one of this different
cheap and enormously scalable processes (tens of thousands) that are
increasing it's value in the industry todays.

	Sorry if I'm being too naif but I had to ask to be able to sleep :)

Sebastian Sastre
PD: I've tried to imagine if this saves us from having to make code trhead
safe or not. I was unable to refutate this by myself so I also ask kindly
that the most experienced and critic minds collaborate on this regard.
 

> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Igor Stasenko
> Enviado el: Domingo, 21 de Octubre de 2007 09:36
> Para: The general-purpose Squeak developers list
> Asunto: Re: Multy-core CPUs
> 
> On 21/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> 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.  The fact is, Erlang has many 
> > processes per image.  Many more then you could ever get as real 
> > processes or native threads (as a test I made a little program that 
> > spawned 64 *thousand* threads and passed messages between 
> them on my 
> > laptop).
> >
> > But with their model, process creation is extremely cheap.  
> And since 
> > there is no sharing as far as the language is concerned, 
> there is no 
> > need for locking to slow everything down.
> >
> > Smalltalk can do this too. I think it needs a little work 
> still, but 
> > I'm optimistic about what can be done here.
> >
> > > However, you'll still end up with concurrency control issues and 
> > > you've got an object version explosion problem occurring as well. 
> > > How will you control concurrency problems with your simplified 
> > > system? Is there a succinct description of the way that 
> Erlang does 
> > > it? Would that apply to Smalltalk?
> >
> > Much like how Smalltalk does it, as it turns out.  That is, 
> you don't 
> > have a version problem so much as you have "old" and "new". 
>  So when 
> > ready you send the "upgrade" message to  the system and all 
> new calls 
> > to the main functions of a process will be the new version.  All 
> > currently running code will access the old code until it's 
> completion, 
> > and all new code runs in the new space.
> >
> > > You simplified concurrency system also dramatically alters the 
> > > Smalltalk paradigm.
> >
> > The current paradigm is fine-grained locked/shared state.  In my 
> > opinion and the opinion of many (probably most in fact, 
> outside of the 
> > Java community) people who are more expert is this area 
> then you or I, 
> > we *have* to move away from this paradigm.
> >
> > > Is this the approach that Cincom is using in their Visual 
> Works system?
> > > They seem to not be embracing the notion of native threads.
> >
> > Thank God. :)
> >
> > > However it's
> > > also unlikely that they are embracing the notion of only ONE 
> > > Smalltalk process per image either.
> >
> > If I understand you correctly, then I would suggest not to use the 
> > word "image" as this is confusing.  Another way to put it would be 
> > "each process has it's own view of the world".  And 
> honestly, what is 
> > the problem you see with this?
> >
> > Right now, if you run two separate images with only one thread or 
> > process, then you have two processes that each have their 
> own set of 
> > objects in their own space interacting with each other.
> >
> > Now we add a way for one image to send a message *between* images.
> > Perhaps the VM can detect when we are trying to do this, 
> but instead 
> > of complicating the default Smalltalk message sending 
> subsystem, lets 
> > make it explicit with some special binary message:
> >
> > Processes at: 'value computer' ! computeValue.
> >
> > Now we have the ability to send messages locally within a 
> process, and 
> > a way of freely sending between processes.  No locking and the 
> > problems associated with locking.
> >
> > So, now what is stopping us from moving this separate 
> process *inside 
> > the same image*?  If you fork a process and he starts 
> making objects, 
> > no other processes have references to those objects.  No 
> shared state 
> > issue there.  This part could work right now today with no 
> changes to 
> > the VM.
> >
> > The only issue I can think of are globals, the most obvious being 
> > class side variables.  Note that even classes themselves are not an 
> > issue because without class side variables, they are effect free 
> > (well, obviously basicNew would have to be looked at).
> >
> > But I think this issue is solvable.  The VM could take a "copy on 
> > write" approach on classes/globals.  That is, a class 
> should be side 
> > effect free (to itself, i.e. it's the same after every 
> call), so let 
> > all processes share the memory space where meta-class objects live.
> > But as soon as any process tries to modify the class in some way 
> > (literally, it would be the class modifying itself), he 
> gets his own 
> > copy.  Processes must not see changes made by other processes, so a 
> > modification to a global class is a "local only" change.
> >
> I don't think this have a sense. Classes should be treated as 
> regular objects (everything is an object - remember?), and 
> due to that fact you can't make preferences over different 
> kind of objects. Class objects and instance objects are the 
> same: objects holding a mutable state.
> A method dictionary is a mutable state of class, so changing 
> it should affect all objects of given class immediately.
> 
> 
> > Of course the only big thing left would be; what happens 
> when we add a 
> > new class.  But Erlang has had success with the old/new space 
> > approach, and what Smalltalk has now is very similar.
> >
> >
> 
> And btw, i starting doubt about 'no sharing at all' paradigm. 
> Just in one of the links you given about Erlang, one of the 
> readers commented:
> (http://armstrongonsoftware.blogspot.com/2006/08/concurrency-i
s-easy.html)
> 
> ---
>  Anonymous said...
>     One of your premises is obviuosly wrong:
> 
>     We don't have shared memory. I have my memory, you have 
> yours, we have two brains, one each, they are not joined together.
> 
>     The premise that the above statement is based on - is 
> that we are not internally concurrent. The earlier statements 
> in your blog entry say that we are. The actuality is that all 
> of our individual (i.e.
> internal) processes are concurrent and share memory. Even 
> including our main conscious "thinking" process.
> 
>     It is our interaction between individuals that doesn't 
> always share memeory and even here we do share memory - many 
> examples (dairies, libaraies, system processes, etc) - in 
> various ways.
> ---
> 
> There an obvious evidence of a system which performs in 
> parallel by having a single shared state - human brain. Do we 
> experience heavy 'locking' or 'concurrency' problems?
> Personally, I'm not :) And if so, then why sharing state 
> should be considered evil?
> 
> Also, in fact, you can't eliminate using shared state at all.
> There can be only a ways how to delegate shared state 
> management to outer context (such as OS, or VM e.t.c).
> A 'fine-grained' locking is nothing more than manual 
> controlling of shared state made by developer.
> Try implement Erlang (or any other system which uses parallel 
> computations and having a shared state) without locks and semaphores.
> There are always something needed to manage the locking, even 
> if it hidden from your eyes. So, tell me, what the difference 
> between manually controlling it, or 'magically', like Erlang does?
> 
> A proposed a message passing between different OS processes(squeak
> images) is nothing more than letting OS deal with shared 
> state problems (locks/queing e.t.c).. naively thinking that 
> we are get rid of shared state concurrency. Are we really do?
> 
> --
> Best regards,
> Igor Stasenko AKA sig.
> 
>