On 04/11/2007, Rob Withers reefedjib@yahoo.com wrote:
----- 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.
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.
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.
Ah, i see. A run-time GC should be designed in a way that it will guarantee that marking will be done before application allocates N bytes of memory.
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.
Err, why? IIRC, an error(exception) initiates a stack unwinding looking for context which can handle it.
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