Concurrent Futures
Joshua Gargus
schwa at fastmail.us
Mon Oct 29 21:34:36 UTC 2007
On Oct 29, 2007, at 1:50 PM, Igor Stasenko wrote:
>
> Lets see , what is happen if we have only a future sends.
> Then, given code:
> a print.
> b print.
>
> will not guarantee that a will be printed before b. Now you must
> ensure that you preserve imperative semantics, which may be done like
> following:
> futureA := a print.
> futureA whenComplete: [ b print ].
No, that's not true. Croquet and E both ensure that the future
messages are processed in the order that they are sent. No
#whenComplete: is required, since the second print expression does
not depend on the first.
>
> Yes, we can make 'futureA whenComplete:' check implicitly (by
> modifying VM), then we can preserve old code. But do we really need a
> futures everywhere?
We don't need futures everywhere. Croquet has chosen to make futures
explicit; your example would be written:
a future print.
b future print.
At least in Croquet (I don't know what a "typical" E program looks
like), future sends are used sparingly... the vast majority of
messages are regular immediate sends.
Josh
More information about the Squeak-dev
mailing list
|