On 10/22/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> If there's nothing else, which can be a replacement to this model ,
> then you don't have a choice, but use above.

The *VM* will have to, but no one using the Smalltalk system would.

> Again, a question raised: how to ensure that messages are passed in
> correct order and  make sure that messages are delivered?

Message delivery is a guarantee of the system, but order is absolutely
not guaranteed.

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

.... I don't get your objection.  Again, the VM abstracts *lots* of
tough details away from us so that we *never* have to think about it.
Yes, in the current OS/Hardware options of course *the VM* will have
to do some synchronization on message "mailboxes", but so what?  It
does memory management for us now and saves us a great burden.

> If you know another way(s) how to make proper message passing scheme
> without using synchronized object (such as queue), i am all ears.

There are things out there, but who cares?  This is a low level detail
the VM can hide from us just fine.  Ask any Erlang programmer how
often they worry about synchronization issues with their message
mailboxes.