On 04/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- 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.

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


-- 
Best regards,
Igor Stasenko AKA sig.