On 29/10/2007, Rob Withers reefedjib@yahoo.com wrote:
----- Original Message ----- From: "Igor Stasenko" siguctua@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)?
Rob