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

Rob