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

>> The other thought I had was that garbage collection in squeak seems to
>> happen when needed, immediately.  Things may be so dire for memory that 
>> it
>> has to do or die.  This would give us a problem making it scheduled as
>> another event, wouldn't it?
>>
>
> What makes you think that futures will die upon GC?
> For working properly, a reference to the future are placed as 'sender
> context' in context of our interest. So, when such context will done
> working and return result, a sender context will be activated  - which
> is our future message send.

Ok, you are sending messages to futures, as am I.   No, the comments about 
GC had to do with a comment made where GC actions are scheduled with normal 
image activities, and I thought they might not be executed when needed.


> I'm personally much more worrying about non-local returns.

Me too.

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

> It seems building long chains of futures is impractical.
>
> Of course, in this case its better ask developer, why he uses futures
> with methods which can do non-local returns. :)

He wants to because the capability is there.  He must use them everywhere. 
:)

Rob