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

> Rob
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.