That's a nice example.  The difference with E's promises is that a Promise 
doesn't block for value, it sends the new msg eventually and returns a 
second promise.  The way I have this implemented in SqueakElib, is you send 
#eventual to get an eventual ref, then you can send a msg to the eventual 
ref, returning a promise, which you can then send a second msg to, returning 
a second promise.

| promise1 promise2 |
promise1 := anObject eventual foo.
promise2 := promise1 bar.
promise1 whenResolved: [:val | Transcript show: ' foo: ', val printString].
promise2 whenResolved: [:val | Transcript show: ' bar: ', val printString].
Transcript show: 'sent foo bar...'

This prevents deadlocks.  This is also very interesting when looked at in a 
distributed system, using Promise Pipelining.  Let us say that anObject 
resides in Vat B on a different machine.  Instead of having a 2 round trip 
communications situation, we have 1 round trip.  So instead of
    1) send #foo, 2) receive fooResult, 3) send bar, 4) receive barResult
We have:
    1) send #foo, 2) send #bar to fooResultPromise, 3) receive barResult.
Where #foo and #bar are both sent to the objects in VatB.  They are sent in 
the same packet.

Rob

----- Original Message ----- 
From: "Peter William Lount" <peter at smalltalk.org>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, October 27, 2007 11:21 AM
Subject: Concurrent Futures


> Hi,
>
> This link will be of interest to those wanting easy concurrency. Works 
> best for simple cases and can be used as a primitive in building up more 
> complex concurrency controls. However, use with caution, especially when 
> larger amounts of code are being executed that could conflict with other 
> threads is involved. This applies even in the single native thread 
> multiple Smalltalk "light weight green" processes environment of most 
> Smalltalks.
>
> http://onsmalltalk.com/programming/smalltalk/smalltalk-concurrency-playing-with-futures/
>
> Cheers,
>
> Peter
>
>