Thoughts on a concurrent Squeak VM
reefedjib at yahoo.com
Sat Nov 3 23:14:05 UTC 2007
----- Original Message -----
From: "Igor Stasenko" <siguctua at gmail.com>
> I found another thing, which may be interesting:
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
>> 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
>> 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.
> 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
> 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.
More information about the Squeak-dev