On 10/22/07, Igor Stasenko siguctua@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.