----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 29, 2007 2:16 PM
Subject: Re: Concurrent Futures


> On 29/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>>
>> ----- Original Message -----
>> From: "Igor Stasenko" <siguctua at gmail.com>
>>
>>
>> > 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.
>>
>> In SqueakElib, it will guarantee order if a and b are in the same Vat and
>> already resolved (not Promises/Futures).  If a is a promise and b is
>> resolved, then they will print out of order.  Likewise, if a is remote 
>> and b
>> is local, they will print out of order.  Msgs to objects in the same Vat 
>> are
>> scheduled in order.
>>
>> > 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?
>>
>> This is what I am trying to do with SqueakElib.  Any old object 
>> referenced
>> in the system is an eventual local ref, but the system should handle
>> promises or non-local refs anywhere.
>>
>> > Or, we using both of them by mixing.. (which i think is most
>> > appropriate).. But then, stating that such system can be really
>> > lock-free, is wrong, because it depends on decision of concrete
>> > developer and his code.
>>
>> We may be able to rewrite Semaphores in terms of promises, and modify
>> Processes to run on a particular vat as an event.  Thus remove possible
>> deadlocks from old code.
>>
>
> Yes we do, but what prevents others from implementing own locking
> semantics based on direct message sends (not futures)?

Remove #primitiveWait from the VM.

Rob