----- Original Message ----- From: "Igor Stasenko" siguctua@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