> > 1. For the correct order: I understand that Erlang is open 
> so, to some 
> > point, nothing stop us from looking that how-tos on how Erlang's VM 
> > makes the message passing in correct order right? Seems to me that 
> > somehow they solved that question and probably we can study 
> how assimilate that virtue.
> 
> While reading this topic, i googled, just to look what 
> solutions are found in this area for non-locking queues.
> There is no wonder (still) - they all based on atomic CaS (Compare and
> Store) processor instructions. Its of course interesting how 
> Erlang manages message passing, but i doubt that it based on 
> something much different.
> 
But I think that until we have async CPU's there allways have to be
implemented someway like that. I see it as a hardware limitation not as a
problem per se. My point is, as you say, that even with that it's very
interesting how they managed to take advantage of it and make such a good
message passing machine and feed the wonder of it being assimilable by the
objects paradigm.

> > 2. For ensuring messages sends: "send and pray"
> >
> > That way when a smalltalk's erlangized message send is in a process 
> > that terminates it should end with some cause for the act 
> of finish. 
> > Maybe this will allow for instance to implement DNU: the VM 
> don't find 
> > a proper method in the object to receive that message so it 
> terminates 
> > the process stating that as cause.
> >
> 
> An 'erlangenization' of sends mean that we need deal 
> differently with contexts. I think best way for this, is to 
> rethink a context to make it look closer to what is a process 
> in Erlang.
> Yes, we must pay the price of making all contexts be real 
> objects for each message send, so we might expect a real 
> slow-down of single thread execution.
> Then the only way how we could regain this loss is to use 
> highly parallelisable algorithms.
> 
> > Cheers,
> >
> > Sebastian
> >
> 
> --
> Best regards,
> Igor Stasenko AKA sig.
> 
I see that consequence but we are forced to think big by healty trends.
Systems todays are kind of optimal for monocore CPU's because they was not
designed for multicore and the adaptation to multicore CPU's has a tradeoff
of releasing that optimization for single processes. But that is a worry
just for what, one or two years? is a very short duration of time to worry
about for. Future seems to have all in favor of parallelization. This is all
about that. Hundreds of cores maybe higher orders of magnitude.

	Cheers,

Sebastian