<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-15"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Peter William Lount schrieb:

<blockquote cite="mid:4720FE68.7060300@smalltalk.org" type="cite">

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <br>

  <br>

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

</blockquote>

That's exactly my gut feeling about the claims of being deadlock free.<br>

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

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

I think this is completely homomorphous to traditional remote message

invocation in its potential for deadlock, just more complicated to

program in...<br>

<br>

Cheers,<br>

Hans-Martin<br>

</body>

</html>