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] pre-exception-handling kind in Compiler).
>
> object eventual ifTrue: [failBlock value].
> ^4
>
> Nothing obvious at compile time...

Hmm, this creates a non-deterministic behavoir each time we using
non-local 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 non-local return we actually should skip D, and jump
directly to state E.
The question is, if both B and C using non-local 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 non-locally,
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.