- 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.
- 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