On Thu, 14 Feb 2008 13:26:55 +0100, Igor Stasenko wrote:

> On 14/02/2008, Klaus D. Witzel wrote:
>
> [waste of time]

Who knows :) we'll see :)

>
>>  Please: let's not waste our time discussing your asynchronous arguments
>>  v.s. my synchronous attempt with HydraSMS.
>>
>
> I'm not trying, what i tried is to understand what you putting in
> 'passing control' and in 'synchronous'.
> Is this means, that you want do following:

First we need to add this:

0] if any operation on either side fails, then the other side fails as  
well, with proper notification *whatsoever*.

> - initiator image sends message to another one (a message payload is
> not really relevant)

1] this part has more: initiator asks the other .image to establish a  
response channel. If handshaking fails, then 0]

> - then waits during another image performs requested operation

No, no RPC. This is Smalltalk land, we want no stinkin' RPC :) instead,

2] then the other .image sends back sufficient payload so that the  
initiator side has the "next" block evaluated, and so on with roles  
swapped, back and forth. If something fails, then 0]

No other part of the method is "resumed-to", on neither side. This is  
meant when I write, unit of transfer is Smalltalk's block. Apologies if I  
didn't make *block* clearer.

May I repeat it? it's *blocks* :) Each block is evaluated on "its" side  
(#atHomeDo: #atWorkDo:), same with a block's blocks.

> - then resuming operations (by receiving notification or return value).

If you would have meant RPC by that: no. All that is transferred, is which  
Smalltalk block on which side is to be evaluated next (recalling that both  
sides are in the same compiled method and let's forget about  
parameter/argument passing for a moment). And Smalltalkers can put  
*everything* inside their blocks :)

-------------

Both sides intentionally return self (but of course they can persist  
parameters/arguments and do with them whatever they please).

/Klaus

P.S. bbl