----- Original Message ----- 
From: "Peter William Lount" <peter at smalltalk.org>


> 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.

It is easy.  The Promise just needs to hold onto pending msgs, sent to the 
result when the promise resolves.  The hard part is getting the Squeak 
environment to behave in the presence of promises.  To that end I added the 
protocol #immediate, which, you guessed it, waits on a Semaphore.  I'll be 
removing that in Phase 3.


> 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).

What are all the classes of possible deadlocks? (Please provide simple 
Squeak examples demonstrating each class of deadlock).   I'll simply refer 
you to http://www.erights.org/elib/concurrency/event-loop.html, see towards 
the bottom.

Cheers,
Rob

>
> 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
>>>
>>>
>>
>>
>>
>
>
>