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