On 22/10/2007, Sebastian Sastre <ssastre at seaswork.com> wrote:
> > > That's the point: you *don't* have synchronized access to
> > any object.
> > > All you have is messages.  Think of it as an OO view of processes.
> > > You can't see what's inside, you can only ask the process
> > to do things
> > > on your behalf.
> > >
> >
> > Again, a question raised: how to ensure that messages are
> > passed in correct order and  make sure that messages are delivered?
> > Now lets look inside: to make it working properly, you need
> > to implement a message queue. And queue means that you must
> > make an 'enqueue' and 'dequeue' operations  synchronized.
> > And that's exactly what i mean: even if you hide the
> > concurrency problems from the eyes of developer, this is not
> > means that problems are gone: now you have to deal with them by own.
> > If you know another way(s) how to make proper message passing
> > scheme without using synchronized object (such as queue), i
> > am all ears.
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
> 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.

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