On Mon, 22 Oct 2007 14:30:28 +0200, Igor Stasenko wrote:
> On 22/10/2007, Sebastian Sastre 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.

Not only slow-down :( For an example, have a look at the implementor of  
#debug:title:full: in class Process, where thisContext is assigned to a  
variable.

When #ifTrue:ifFalse: is really sent, ([thisContext] class) is  
BlockContext *and* its sender is nil so the test for #hasContext: in the  
next statement fails.

But Squeak's compiler [usually] doesn't emit code for sending  
#ifTrue:ifFalse: so ([thisContext] class) is MethodContext and  
#hasContext: doesn't fail (in this example).

> Then the only way how we could regain this loss is to use highly
> parallelisable algorithms.

... which can be employed regardless of 'erlangenization' :)

/Klaus

>> Cheers,
>>
>> Sebastian
>>
>