On 04/11/2007, Rob Withers reefedjib@yahoo.com wrote:
----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@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@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.
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.
True, but not for non-local returns.
Rob