What would Squeak be like without nonlocal returns
Igor Stasenko
siguctua at gmail.com
Wed Nov 7 05:04:28 UTC 2007
On 07/11/2007, nicolas cellier <ncellier at ifrance.com> wrote:
> It seems like everything after has to become eventual.
> But worse, some inst var could contain blocks with local return (see
> ifFail: [^nil] preexceptionhandling kind in Compiler).
>
> object eventual ifTrue: [failBlock value].
> ^4
>
> Nothing obvious at compile time...
Hmm, this creates a nondeterministic behavoir each time we using
nonlocal returns in futures.
suppose we having execution flow:
A
/ \
B C
\ /
D

E
Where A is our initial state where we divide our execution in two
parallel threads B and C (one of them considered as future).
Then, at some point we have both of them resolved and merged to single
thread again (D).
But in case of nonlocal return we actually should skip D, and jump
directly to state E.
The question is, if both B and C using nonlocal return, then which of
them should be granted as a result of computation? One, which emerged
from B, or from C?
If we use 'first who is done  is winner' rule, then it makes our
system very unpredictable, because due to scheduling there can be
situations where either B or C can return first even given same input
in algorithm.
Ok, then we come to point, that if one of them are exited nonlocally,
we must wait for completion of another one, and only then decide which
result to use..
But question is stays: which return result to use?

Best regards,
Igor Stasenko AKA sig.
More information about the Squeakdev
mailing list
