What would Squeak be like without non-local returns
jason.johnson.081 at gmail.com
Sat Nov 10 16:30:55 UTC 2007
I think you guys are over complicating this. Return to a home context
from a future doesn't make any sense and should just toss an error, as
returning to a home context that no longer exist does now.
E style futures are basically some code asking a process somewhere
else to do something, and giving you the ability to attach a callback
for when the other process is finished. I don't think it make sense
to have the remote code return to some context that isn't in it's
address space, and allowing home context returns in the callback is
certainly a bad idea, as the home context should not still be around
when the callback runs.
On Nov 7, 2007 5:00 AM, Rob Withers <reefedjib at yahoo.com> wrote:
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> >> Knowing we have blocks in play within the execution of a method, we say
> >> we
> >> want to synchronize the execution of the method and not run it
> >> eventually.
> >> How do we do this?
> > Ok, lets look again on the problem.
> > Consider a code:
> > --
> > f := object future doSomeThing: someBlock.
> > a := a + 1.
> > f doSomeThingElse.
> > --
> > Semantically, if block (someBlock) does non-local return, that means
> > that next statements should not be evaluated at all means, because
> > this could lead to unpredictable behavior.
> Does it mean this? Because this violates the rule that there should be no
> blocking. Msgs should just be sent. Maybe the rule in play is that
> someBlock does a non-local return that is no longer valid, because it was
> scheduled eventually outside the scope of the method it could return from,
> so it should cause an Error and the return value of doSomeThing: is a broken
> ref. A way out of this pickle?
> > But there is no ways how to prevent that:
> > - any piece of code in #doSomeThing: can send a message to object(s)
> > which lead to execution of non-local returns or throwing an exception
> > causing stack unwinding.
> Ok, but if what I just said holds, then the unwinding terminates where the
> msg was eventually sent and never gets to interact with the sending context.
> > This means that if you using futures/promises in your code, you can't
> > make this code to be semantically equivalent as with not using them.
> I think that's true.
> > In that way, i think, its better to think of how to prevent obvious
> > pitfalls and give developer a clear ways how to use eventual refs
> > safely or teach them (in some manner), that writing a code with
> > futures is something different than writing same code in imperative
> > fashion.
> Yes, it is not transparent. On the other hand, any ref could be eventual.
> So the rules for how they behave in various imperative situations are
> important. As to how to write our example clearly, in the eventual style:
> f := object future doSomeThing: someBlock.
> f whenResolved: [:fVow |
> a := a + 1.
> fVow doSomeThingElse].
More information about the Squeak-dev