Peter William Lount schrieb:
>
>
> 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.
That's exactly my gut feeling about the claims of being deadlock free.
As far as I understood it, in E, processes can't "wait" for messages
while they are processing one message. Each process (or Vat) has a loop
which receives and processes one message at a time. There is no way for
a process to wait for something else, it may only send messages to other
processes.
Wherever you would have a remote message invocation in a traditional
distributed system, E forces you to write an explicit continuation: put
all your current state in an object and pass a handle that object as
part of a message to a remote object. When that remote object has
computed a result, this result is sent to your state object, which
performs the next steps.
I think this is completely homomorphous to traditional remote message
invocation in its potential for deadlock, just more complicated to
program in...

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