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