----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, November 03, 2007 4:57 PM
Subject: Re: Thoughts on a concurrent Squeak VM


> On 04/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>>
>> ----- Original Message -----
>> From: "Igor Stasenko" <siguctua at gmail.com>
>>
>> > I found another thing, which may be interesting:
>> > http://www.stackless.com/
>>
>> Ok, I took a look and I decided I do not like Python.  :)   What a 
>> horrible
>> syntax.
>
> I don't like a python myself, a two weeks of programming on it was
> enough for the rest of my life ;) But i pointed more on concepts which
> allowed concurrency in Python VM , and i think we can learn on their
> experience.
>
>> On the topic of microstacks in stackless, I figure we already do
>> this in Squeak.  Each method has a stack and the msg sending is like the
>> channel comms.
>
> Not exactly. See, the one main difference, i think, that we can't
> lookup for a method before all arguments are evaluated even for known
> receiver.
>
> I mean that in code:
>
> object1 method1: object2 method2
>
> we can't do lookup for #method1 before done evaluating a method2,
> because in method2 there can't be things which can change the class of
> object.
> Thus, we need to push args on stack or create an argument-vector  to
> collect all arguments, and then, only after having all of them, we can
> actually do lookup and create a context for receiver's method.

Unless you are using futures. :)  In that case the invocation schedules the 
message for later, and we move to sending method1: before method2 is 
evaluated.  Even if method2 changes the class of object1, it just happened 
to late to be of importance.


>> >
>> > If we suppose that we built a chain of future message sends in:
>> >
>> > object future message1 message2 message3 ... messageN.
>> >
>> > then if an error occurs in message1 (or there is non-local return), it
>> > means that all chain of futures, which awaits for activation (message2
>> > ... messageN) should be thrown overboard.
>>
>> Actually, the error should propogate through all future msgs, not thrown
>> overboard.
>>
>
> Err,  why? IIRC, an error(exception) initiates a stack unwinding
> looking for context which can handle it.

object future message1 throws an error.  message2 will now be sent to this 
error and will itself break with an error, and so on up the line.  It is 
another way of propogating errors.

Rob