Promises (was: Re: Light-weight monitor implementation?)
Colin Putney
cputney at wiresong.ca
Thu Nov 3 13:19:56 UTC 2005
On Nov 3, 2005, at 7:41 AM, Cees De Groot wrote:
> http://www.erights.org/elib/distrib/pipeline.html and other pages
> on that site.
>
> One of the biggest differences is that you can perform computations
> with promises - the result is another promise, etcetera. Only when you
> really really really need to do something acute to the promise you end
> up with, you block waiting for all the work to finish.
>
> So:
>
> foo := [1 + 2] asPromise.
> bar := foo + 3
> "bar is now a promise if foo wasn't finished yet, so doesn't block"
> Transcript show: bar printString; cr.
> "now we need to value of the whole thing, so that blocks"
>
> At least, that's what I seem to remember. Disclaimer: I'm getting
> seriously old so more and more memory cells are failing...
You also need to be able to handle broken promises. What if that
block never does produce an answer? So something more like:
foo := [1 + 2] asPromise.
"this doesn't block, but bar is a promise as well."
bar := foo + 3
"this does block, but not indefinitely."
bar
resolveIn: [:answer | Transcript show: answer printString; cr]
onTimeout: [Transcript show: 'promise timed out'; cr].
E makes a syntactic distinction between immediate sends and eventual
sends, so that if you try to make an immediate send to a promise
you'll get an error. Bert, how does the Croquet version handle this?
Do you just keep getting promises until you explicitly wait for
resolution?
Colin
More information about the Squeak-dev
mailing list
|