David Hopwood wrote:
Please read my other post for the terminology I'm using. I think it is
self-consistent and consistent with the literature.
I won't fight with you about terminology. That was not the point.
Calling E's promises "futures" would not be consistent with how the term
"future" has been used in other languages (e.g. MultiLisp and Alice ML).
Futures are bound by a specific thread (usually a thread created with the
future); E's promises can be bound by any code that has access to the
promise's resolver.
Alice's promises are called "handled futures", and Java's "FutureTask" :-P
Dataflow makes all this machinery dynamic and implicit.
Implicit waiting may seem more convenient, but it's not compatible with
E's event loop concurrency model. The advantages of this model in avoiding
deadlock and race conditions are explained in
<http://www.erights.org/talks/promises/paper/tgc05.pdf>.
Explicit waiting does not lead to any loss of expressiveness.
We already had discussions like this with Mark Miller (E's designer). I
don't buy his argument. Deadlocks and race conditions come from shared
state concurrency. It is actually easier to avoid shared state in Oz
than in E...
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
