Hi Rob,

That sounds quite interesting - chains of promises until the results 
start flowing. It should be easy to adapt the 
http://onsmalltalk.com/programming/smalltalk/smalltalk-concurrency-playing-with-futures 
example implementation to do the same kind of deferral.

Of all the classes of possible deadlocks which do the E promises help 
resolve? (Please don't say all unless you back up such a general 
statement with a proof. Thanks).

All the best,

Peter




Rob Withers wrote:
> 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
>>
>>
>
>
>