Hi Andreas,

Glad you weren't scared off by this thread. :)

(comments below)

On 10/25/07, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> Deadlock can only happen if one process waits for another. E does
> *never* wait, there is no wait instruction. Instead, it schedules a
> message to be run when the desired computation completes. This leaves
> the Vat free to execute other messages in the meantime. In Croquet, this
> looks like here:
>
>    "future is Croquet's variant for sending async messages"
>    promise := rcvr future doSomething.
>    promise whenResolved:[:value|
>         "do something with the result of the computation
>           this block will executed once the concurrent computation
>          is completed and the response message is being processed
>          in this Vat/Island."
>    ].

This is interesting.  Is this already truly parallel in Croquet (or
even E for that matter)?

The thing I have always worried about with futures is data versioning.
 For example, if you have a really big chunk of data that gets passed
to another process, how does that work?

In an Erlang model, the process would simply block until it had copied
the entire structure and sent it.  In a future model you don't have to
do that (right?), but don't you have to do a local in-image copy to
ensure that the local process doesn't mutate the structure while it's
being traversed by the remote reading process?  Or perhaps I'm missing
something.

> Because there is no wait, "classic deadlock" simply cannot happen. There
> is an equivalent situation which is called "data lock" where circular
> dependencies will cause a computation not to make progress (because a is
> computed in response to the completion of b, b in response to completion
> of c and c in response of completion of a). But there are *major*
> differences to deadlocks: First, datalock is deterministic, it only
> depends on the sequence of messages which can be examined. Second,
> because the Vat is *not* blocked, you are free to send further messages
> to resolve any one of the dependencies and continue making progress.
>
> In other words, the "control flow problem" of deadlock has been turned
> around into a "data flow problem" (promises and completion messages)
> with much less dramatic consequences when things go wrong.
>
> Cheers,
>    - Andreas

Yes this is indeed quite interesting.  Do you have a feel for how
complex the futures model is, and how complex it would be to make it
truly parallel (assuming it isn't already)?