Peter,
 
Of all the links you have been given, put this one at the top of your list.  Commit to spending an half hour reading, much less than this thread!  :)
 
>    (concerning distributed programming, and event-loop concurrency)
>    http://www.erights.org/elib/index.html


I also wasn't as clear as I could have been.

> When a message is sitting in an inbound queue on a process waiting 
> for that process to do get to it it is in essence blocked until it gets 
> processed. If the process is only processing one inbound message at 
> once it is possible for a dead lock to occur when multiple processes 
> are in a similar situation with each other. Both processes waiting for 
> the message that would let them continue which is sitting blocked on 
> the other's queue. That's all. Classic deadlock case. 

Ok, with your terminology, and some of mine, a message in a queue feeding a Vat is blocked until the Vat gets to it.  Ditto with Vat 2.  The mistake in your classic deadlock case is to assume that the message could also get blocked because it is waiting on the msg in Vat 2.  This does not happen.  If there was an unresolved reference waiting on resolution from a remote computation, it is represented as a promise.  So message 1 would have a promise for the outcome of message 2.  It would NOT be on the queue for Vat 1.  It would be sitting as the argument in a #whenMoreResolved msg to the promise.  And when that promise resolves, it would then run.  

Now, you are further saying that promise will not resolve because both are mutually dependent on each others results.  So you are saying that in a sense they are deadlocked.  Again this cannot happen.  There is no way for you to kick off computation 1, with the promise to computation 2, unless the computation 2 had already been kicked off.  DItto for the other direction.  So it is impossible to construct this promise deadlock.

Cheers,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071025/eaff8fe3/attachment.htm