[E-cvs] cvs commit: e/doc/elib/distrib obj-passing.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Wed, 9 May 2001 01:00:42 -0400
markm 01/05/09 01:00:42
Modified: doc toc.txt
doc/elang/concurrency epimenides.html introducer.html
doc/elib/concurrency event-loop.html msg-passing.html
partial-order.html semi-transparent.html turns.html
vat.html
doc/elib/distrib obj-passing.html
Log:
lots of typos. Thanks to Darius Bacon
Revision Changes Path
1.40 +1 -0 e/doc/toc.txt
Index: toc.txt
===================================================================
RCS file: /cvs/e/doc/toc.txt,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- toc.txt 2001/05/07 08:29:24 1.39
+++ toc.txt 2001/05/09 05:00:41 1.40
@@ -65,6 +65,7 @@
GCAnswerOp.html
ShutdownOp.html
TerminatedOp.html
+ WormholeOp.html
#
NewFarDesc.html
NewRemoteVowDesc.html
1.27 +10 -10 e/doc/elang/concurrency/epimenides.html
Index: epimenides.html
===================================================================
RCS file: /cvs/e/doc/elang/concurrency/epimenides.html,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- epimenides.html 2001/04/30 20:36:05 1.26
+++ epimenides.html 2001/05/09 05:00:41 1.27
@@ -108,7 +108,7 @@
her reference to Bob is a <i>local</i> reference. A reference is <i>local</i>
if </p>
<ol>
- <li>both the arrow head and the arror tail are in the same Vat, and </li>
+ <li>both the arrow head and the arrow tail are in the same Vat, and </li>
<li>if the arrow head is already attached to an object.</li>
</ol>
<p>Once a reference is local it will be forever local, and it will always
@@ -116,15 +116,15 @@
a message sent on it to this object. Conventional single-address-space
object-oriented programming (sasoop) has only the equivalent of local
references.</p>
- <p>The other possible states for a reference are <i>deferred</i> and <i>broken</i>.
- A reference that crosses between machines is deferred, as is a reference
- whose arrow head isn't yet attached to an object. When you use a variable
- on the right side of a definition that will be defined on the left side,
- during the execution of this right side, the value of variable is a deferred
- reference designating the object that the variable will be initialized
- to. It is the tail of an arrow whose head will be hooked by, but it doesn't
- get hooked up until after the right side finishes executing. We also refer
- to this as a <i>promise</i> for the value of the variable.</p>
+ <p>The other possible states for a reference are <i>deferred</i> and <i>broken</i>.
+ A reference that crosses between machines is deferred, as is a reference
+ whose arrow head isn't yet attached to an object. When you use a variable
+ on the right side of a definition that will be defined on the left side,
+ during the execution of this right side, the value of the variable is
+ a deferred reference designating the object that the variable will be
+ initialized to. It is the tail of an arrow whose head will be hooked up,
+ but it doesn't get hooked up until after the right side finishes executing.
+ We also refer to this as a <i>promise</i> for the value of the variable.</p>
<p>Since there's not yet an object on the other side of the arrow, a <i>do
it now</i> message pass results in the above error. However, we can use
E's <i>do it eventually</i> message pass, the asynchronous send operator:<br>
1.33 +7 -7 e/doc/elang/concurrency/introducer.html
Index: introducer.html
===================================================================
RCS file: /cvs/e/doc/elang/concurrency/introducer.html,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- introducer.html 2001/04/13 19:23:51 1.32
+++ introducer.html 2001/05/09 05:00:41 1.33
@@ -206,13 +206,13 @@
</blockquote>
</blockquote>
</blockquote>
- <p>Alternatively, if you have windows to both processes in front of you,
- you can just copy and paste from one two the other. Or you could email
- the uri to an account you can read on the other machine -- whatever works.
- This is the act of <i>initial introduction</i>. In situations where security
- is important you must convey this string from one process to the other
- in a secure manner, such as in a PGP-encrypted email message. Assuming
- this has been done, E ensures that all further communication between these
+ <p>Alternatively, if you have windows to both processes in front of you,
+ you can just copy and paste from one to the other. Or you could email
+ the uri to an account you can read on the other machine -- whatever works.
+ This is the act of <i>initial introduction</i>. In situations where security
+ is important you must convey this string from one process to the other
+ in a secure manner, such as in a PGP-encrypted email message. Assuming
+ this has been done, E ensures that all further communication between these
processes remains secure. </p>
<p align="center"><img src="images/uri-intro.gif" width="308" height="312"></p>
<p>This act of introduction is another example of the <a href="../../elib/capability/ode/index.html">Granovetter
1.7 +2 -2 e/doc/elib/concurrency/event-loop.html
Index: event-loop.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/event-loop.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- event-loop.html 2001/02/26 08:31:25 1.6
+++ event-loop.html 2001/05/09 05:00:41 1.7
@@ -93,7 +93,7 @@
</ul>
<p> <i>(For more on steps 1, 2, and 3, see <a href="../capability/ode/ode-objects.html">this</a>.)</i></p>
</li>
- <li>Much of the charm of pure Lambda Calculus is its blissfully ignorance
+ <li>Much of the charm of pure Lambda Calculus is its blissful ignorance
of all issues of time and execution order. Arithmetic is beautifully
timeless in the same sense. Unfortunately, once we add side-effects,
we have to come to terms with these issues. Solutions that enable us,
@@ -180,7 +180,7 @@
method must obtain a lock on the counter object as a whole before proceeding
into the method body, and that it should release this lock on exit. For
this counter, the above code is unproblematic. However, in general the
- method body with call other methods on other objects. This means the thread
+ method body will call other methods on other objects. This means the thread
will be holding some locks (on objects whose synchronized methods are
part-way through execution) while waiting to obtain other locks. This
is a formula for deadly embrace. To write correct thread-based programs,
1.13 +173 -173 e/doc/elib/concurrency/msg-passing.html
Index: msg-passing.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/msg-passing.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- msg-passing.html 2001/04/17 23:08:29 1.12
+++ msg-passing.html 2001/05/09 05:00:41 1.13
@@ -46,60 +46,60 @@
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
+ <!-- #BeginEditable "LongBody" -->
<h1>Taxonomy of Messaging Primitives</h1>
<p>E has the following message passing primitives, </p>
- <p align="left">
+ <p align="left">
<ul>
- <li> i) the synchronous <i>immediate</i> <b><a href="#call">call</a></b>
+ <li> i) the synchronous <i>immediate</i> <b><a href="#call">call</a></b>
(*)</li>
- <li>ii) the synchronous <b><a href="#outcome">outcome</a></b>, which has
- three sub-cases
+ <li>ii) the synchronous <b><a href="#outcome">outcome</a></b>, which has
+ three sub-cases
<ol>
<li><b><a href="#success">Success</a></b>: evaluation to a result</li>
<li><b><a href="#failure">Failure</a></b>: throw()ing a problem report</li>
<li><b><a href="#escape">Escape</a></b>: like break() or continue()</li>
</ol>
</li>
- <li>iii) the asynchronous <i>eventual</i> ("<-") <b><a href="#send">send</a></b>,
- where an outcome report
+ <li>iii) the asynchronous <i>eventual</i> ("<-") <b><a href="#send">send</a></b>,
+ where an outcome report
<ol>
<li> is not expected -- the <b><a href="#sendOnly">sendOnly</a></b>.</li>
- <li> may be expected -- the <a href="#pipe-send"><b>pipelined send</b></a>
+ <li> may be expected -- the <a href="#pipe-send"><b>pipelined send</b></a>
(*)</li>
</ol>
</li>
</ul>
- <p>For all of these, a message is conveyed to an individual recipient, and
- contains at least a verb (a String) and a tuple of arguments. A message
- often represents a request (identified by the verb and the number of arguments,
- but not their types), so the recipient generally knows why it is receiving
- new authority. This facilitates the programming of non-confusable <a href="../capability/deputy.html">deputies</a>.
- For the cases marked with (*), the message additionally contains a <i>continuation</i>
- -- the object to which the outcome of performing the request should be
+ <p>For all of these, a message is conveyed to an individual recipient, and
+ contains at least a verb (a String) and a tuple of arguments. A message
+ often represents a request (identified by the verb and the number of arguments,
+ but not their types), so the recipient generally knows why it is receiving
+ new authority. This facilitates the programming of non-confusable <a href="../capability/deputy.html">deputies</a>.
+ For the cases marked with (*), the message additionally contains a <i>continuation</i>
+ -- the object to which the outcome of performing the request should be
reported.</p>
- <p align="left"><img src="images/call.gif" width="178" height="215" align="right">E
- computation only occurs within a stack frame -- shown as a lightning bolt
- within an object. A stack frame happens when an object receives a call
- or send/sendOnly. Recall that an object is an instance of an object expression,
- and combines the behavior this expression describes with the state from
- its instantiating context (the scope in which the object expression was
- evaluated). Similarly, a stack frame can be seen as an instance of the
- method or matcher corresponding to the received message, and combines
- the described behavior with state as well. The stack frame’s state is
- the object’s state plus the state resulting from matching the incoming
- message with the head of the method or matcher. During its execution,
- a stack frame can accumulate more state by defining new variables.
- <p align="left">Since all computation happens only within stack frames,
- all messages are emitted only from stack frames. When object-granularity
- analysis suffices, as it often does for security reasoning, we often skip
- illustrating the stack frames, as in the <a href="../capability/ode/index.html">Granovetter
- Diagram</a>.
+ <p align="left"><img src="images/call.gif" width="178" height="215" align="right">E
+ computation only occurs within a stack frame -- shown as a lightning bolt
+ within an object. A stack frame happens when an object receives a call
+ or send/sendOnly. Recall that an object is an instance of an object expression,
+ and combines the behavior this expression describes with the state from
+ its instantiating context (the scope in which the object expression was
+ evaluated). Similarly, a stack frame can be seen as an instance of the
+ method or matcher corresponding to the received message, and combines
+ the described behavior with state as well. The stack frame’s state is
+ the object’s state plus the state resulting from matching the incoming
+ message with the head of the method or matcher. During its execution,
+ a stack frame can accumulate more state by defining new variables.
+ <p align="left">Since all computation happens only within stack frames,
+ all messages are emitted only from stack frames. When object-granularity
+ analysis suffices, as it often does for security reasoning, we often skip
+ illustrating the stack frames, as in the <a href="../capability/ode/index.html">Granovetter
+ Diagram</a>.
<h2 align="left"><a name="call"></a>i) The Immediate Call</h2>
- <p align="left">The above diagram and the following code illustrates Alice
- synchronously calling Bob:
- <p align="left">
- <blockquote>
+ <p align="left">The above diagram and the following code illustrates Alice
+ synchronously calling Bob:
+ <p align="left">
+ <blockquote>
<pre>def alice {
to msg1() {
def result := bob msg2(carol)
@@ -107,51 +107,51 @@
}
}</pre>
</blockquote>
- <p align="left">The call is only allowed if the reference to the recipient
- is <font color="#009900"><b>NEAR</b></font>. Otherwise, the attempt to
- call instead throws an appropriate exception.
- <p align="left"><img src="images/stackchain.gif" width="216" height="265" align="right">Besides
- the components shared by all messages, a synchronous call contains an
- additional special argument -- the continuation -- that points at the
- caller’s stack frame. The call also turns the calling stack frame from
- active to suspended. Computation in fact occurs only in active stack frames.
- A suspended stack frame must be pointed to exactly by one special continuation
- argument. An active stack frame is not pointed at. There can be at most
- one active stack frame in a Vat, and all stack frames are in a linear
- chain between it and a <i>top stack frame</i> -- a stack frame directly
- spawned to service a pending delivery. (When between turns, there are
- no stack frames, as happens when the queue is empty, or when a Vat is
- sitting on disk waiting to be revived from checkpoint.)
- <p align="left">The message passed in a call need not be allocated as a
- separate object, as no time passes between departing from the caller and
- arriving at the callee. Rather, the act of calling simultaneously creates
- the receiving stack frame in the callee. All stack frames contain the
- special continuation argument from the message they received, but -- unlike
- the other arguments received from the message -- the continuation is not
- explicitly accessible to the program.
- <p align="left">See also the <a href="../../elang/kernel/CallExpr.html">Kernel-E
- Call Expression</a>.
- <h2 align="left"><a name="outcome"></a>ii) Synchronous Outcome of Stack-Frame
+ <p align="left">The call is only allowed if the reference to the recipient
+ is <font color="#009900"><b>NEAR</b></font>. Otherwise, the attempt to
+ call instead throws an appropriate exception.
+ <p align="left"><img src="images/stackchain.gif" width="216" height="265" align="right">Besides
+ the components shared by all messages, a synchronous call contains an
+ additional special argument -- the continuation -- that points at the
+ caller’s stack frame. The call also turns the calling stack frame from
+ active to suspended. Computation in fact occurs only in active stack frames.
+ A suspended stack frame must be pointed to by exactly one special continuation
+ argument. An active stack frame is not pointed at. There can be at most
+ one active stack frame in a Vat, and all stack frames are in a linear
+ chain between it and a <i>top stack frame</i> -- a stack frame directly
+ spawned to service a pending delivery. (When between turns, there are
+ no stack frames, as happens when the queue is empty, or when a Vat is
+ sitting on disk waiting to be revived from checkpoint.)
+ <p align="left">The message passed in a call need not be allocated as a
+ separate object, as no time passes between departing from the caller and
+ arriving at the callee. Rather, the act of calling simultaneously creates
+ the receiving stack frame in the callee. All stack frames contain the
+ special continuation argument from the message they received, but -- unlike
+ the other arguments received from the message -- the continuation is not
+ explicitly accessible to the program.
+ <p align="left">See also the <a href="../../elang/kernel/CallExpr.html">Kernel-E
+ Call Expression</a>.
+ <h2 align="left"><a name="outcome"></a>ii) Synchronous Outcome of Stack-Frame
Completion</h2>
- <p align="left">The callee can use the continuation only by completing the
- execution of its stack frame, thereby also causing it to be discarded.
- The nature of this completion implicitly passes an outcome message to
- the continuation. Unlike calls and returns, outcome messages have no hidden
- arguments. There are three kinds of outcome, each represented with its
- own outcome message. When the continuation is a stack frame, these outcome
- messages are only for expository purposes, as neither the caller nor callee
- can deal with them explicitly. We choose describe these as messages so
- we can understand all transfer of authority in terms of the <a href="../capability/ode/index.html">Granovetter
- diagram</a>.
- <p align="left">
+ <p align="left">The callee can use the continuation only by completing the
+ execution of its stack frame, thereby also causing it to be discarded.
+ The nature of this completion implicitly passes an outcome message to
+ the continuation. Unlike calls and returns, outcome messages have no hidden
+ arguments. There are three kinds of outcome, each represented with its
+ own outcome message. When the continuation is a stack frame, these outcome
+ messages are only for expository purposes, as neither the caller nor callee
+ can deal with them explicitly. We choose describe these as messages so
+ we can understand all transfer of authority in terms of the <a href="../capability/ode/index.html">Granovetter
+ diagram</a>.
+ <p align="left">
<ol>
- <li><a name="success"></a><img src="images/completion.gif" width="149" height="215" align="right"><b>Success</b>,
- corresponding to “falling off the end” and represented by passing a
- “<code>resolve(result)</code>” message to the continuation. The diagram
- and the following code illustrate Bob returning Dana as a successful
- result to Alice:
- <p align="left">
- <blockquote>
+ <li><a name="success"></a><img src="images/completion.gif" width="149" height="215" align="right"><b>Success</b>,
+ corresponding to “falling off the end” and represented by passing a
+ “<code>resolve(result)</code>” message to the continuation. The diagram
+ and the following code illustrate Bob returning Dana as a successful
+ result to Alice:
+ <p align="left">
+ <blockquote>
<pre>def bob {
to msg2(carol) {
... <font face="Times New Roman, Times, serif">//whatever
@@ -159,16 +159,16 @@
}
}</pre>
</blockquote>
- <p>In this case, the call expression with which Alice called Bob evaluates
- to this result, and the stack frame in Alice suspended on this call
+ <p>In this case, the call expression with which Alice called Bob evaluates
+ to this result, and the stack frame in Alice suspended on this call
expression continues from this point.</p>
- <li>
- <p align="left"><b><a name="failure"></a>Failure</b>, as a result of
- execution of a “<code>throw(problem)</code>” and represented by passing
- a “<code>smash(problem)</code>” message to the continuation. The following
- code:
- <p align="left">
- <blockquote>
+ <li>
+ <p align="left"><b><a name="failure"></a>Failure</b>, as a result of
+ execution of a “<code>throw(problem)</code>” and represented by passing
+ a “<code>smash(problem)</code>” message to the continuation. The following
+ code:
+ <p align="left">
+ <blockquote>
<pre>def bob {
to msg2(carol) {
... <font face="Times New Roman, Times, serif">//whatever</font>
@@ -177,72 +177,72 @@
</font> }
}</pre>
</blockquote>
- <p align="left">can be illustrated with the same diagram, but the verb
- is now “<code>smash</code>” instead of “<code>resolve</code>”. Execution
- within Alice's stack frame now skips to the closest enclosing <a href="../../elang/kernel/CatchExpr.html">try-catch</a>
- or <a href="../../elang/kernel/FinallyExpr.html">try-finally</a> expression.
- If these are none, then Alice's stack frame completes in failure as
- well, and the <code>smash(problem)</code> message gets forwarded to
- Alice's stack frame's continuation, if any.
- <p>
- <li>
- <p align="left"><b><a name="escape"></a>Escape</b>, corresponding to
- invoking a non-disabled ejector (as created by an <code><a href="../../elang/kernel/EscapeExpr.html">escape</a></code><a href="../../elang/kernel/EscapeExpr.html">
- expression</a>), and represented by passing “<code>eject(ejection)</code>”
- to the continuation. (** need explanation of Ejectors and ejections)
- <p>
+ <p align="left">can be illustrated with the same diagram, but the verb
+ is now “<code>smash</code>” instead of “<code>resolve</code>”. Execution
+ within Alice's stack frame now skips to the closest enclosing <a href="../../elang/kernel/CatchExpr.html">try-catch</a>
+ or <a href="../../elang/kernel/FinallyExpr.html">try-finally</a> expression.
+ If these are none, then Alice's stack frame completes in failure as
+ well, and the <code>smash(problem)</code> message gets forwarded to
+ Alice's stack frame's continuation, if any.
+ <p>
+ <li>
+ <p align="left"><b><a name="escape"></a>Escape</b>, corresponding to
+ invoking a non-disabled ejector (as created by an <code><a href="../../elang/kernel/EscapeExpr.html">escape</a></code><a href="../../elang/kernel/EscapeExpr.html">
+ expression</a>), and represented by passing “<code>eject(ejection)</code>”
+ to the continuation. (** need explanation of Ejectors and ejections)
+ <p>
</li>
</ol>
- <p align="left">Both Failure and Escape are forms of non-local exit.
- <p align="left">Other than by invoking its continuation, the callee cannot
- stop executing, even on I/O. I/O operations that would normally block
- are instead handled by requesting notification be delivered -- by sending
- -- to a designated object. As a result, E is strongly deadlock-free (but
- is still subject to live-lock by infinite loops).
+ <p align="left">Both Failure and Escape are forms of non-local exit.
+ <p align="left">Other than by invoking its continuation, the callee cannot
+ stop executing, even on I/O. I/O operations that would normally block
+ are instead handled by requesting notification be delivered -- by sending
+ -- to a designated object. As a result, E is strongly deadlock-free (but
+ is still subject to live-lock by infinite loops).
<h2 align="left"><a name="send"></a>iii) The Eventual Send</h2>
<div align="center"></div>
- <p align="left">Returning to the human world for a moment, as I schedule
- my time, I find I mainly use two patterns: If in performing task X I find
- I’m blocked on the outcome of a subtask Y, I put the X aside for awhile,
- work on Y until its done, and then continue with X. This corresponds to
- synchronous <i>do it immediately</i>, or call-return scheduling as explained
- above. The other pattern is that, in performing task X, I come to realize
- another task Y I need to perform, but I don’t need to do Y now. To ensure
- I don’t forget Y, I jot a note on a to-do list, and then continue with
- my present task.
- <p align="left">This latter pattern corresponds to asynchronous<i> do it
- eventually</i> scheduling, as supported by the eventual send. A send is
- written like a synchronous call, but with a “<code><-</code>”, the <i>eventually</i>
- operator, between the recipient and the message. A record that this message
- must be delivered to this recipient is duly noted, but then the original
- turns continues about its business unaffected.
- <p align="left"><img src="images/sendOnly.gif" width="178" height="215" align="right">There
- are two forms of eventual send, written the same way, but distinguished
- by whether the value of send expression appears to be needed.
- <p align="left">
- <p>
+ <p align="left">Returning to the human world for a moment, as I schedule
+ my time, I find I mainly use two patterns: If in performing task X I find
+ I’m blocked on the outcome of a subtask Y, I put the X aside for awhile,
+ work on Y until it's done, and then continue with X. This corresponds
+ to synchronous <i>do it immediately</i>, or call-return scheduling as
+ explained above. The other pattern is that, in performing task X, I come
+ to realize another task Y I need to perform, but I don’t need to do Y
+ now. To ensure I don’t forget Y, I jot a note on a to-do list, and then
+ continue with my present task.
+ <p align="left">This latter pattern corresponds to asynchronous<i> do it
+ eventually</i> scheduling, as supported by the eventual send. A send is
+ written like a synchronous call, but with a “<code><-</code>”, the <i>eventually</i>
+ operator, between the recipient and the message. A record that this message
+ must be delivered to this recipient is duly noted, but then the original
+ turn continues about its business unaffected.
+ <p align="left"><img src="images/sendOnly.gif" width="178" height="215" align="right">There
+ are two forms of eventual send, written the same way, but distinguished
+ by whether the value of send expression appears to be needed.
+ <p align="left">
+ <p>
<ol>
- <li>
- <p><a name="sendOnly"></a><b>sendOnly</b>. When a send expression appears
- in a context where it is statically apparent that the value of the
+ <li>
+ <p><a name="sendOnly"></a><b>sendOnly</b>. When a send expression appears
+ in a context where it is statically apparent that the value of the
send expression will be unused, such as to the left of a semi-colon:</p>
- <blockquote>
+ <blockquote>
<pre>bob <- foo(carol); ...</pre>
</blockquote>
- <p>then the message is a pure one-way message containing only the verb
- ("foo") and a list of the explicit arguments ([carol]),
- just as shown in the basic Granovetter diagram. The only feedback
- Alice can get from the performance of the message is that she explicitly
- arranges for. When Bob finishes processing the message, he reports
- the outcome of the turn to no one.</p>
+ <p>then the message is a pure one-way message containing only the verb
+ ("foo") and a list of the explicit arguments ([carol]),
+ just as shown in the basic Granovetter diagram. The only feedback
+ Alice can get from the performance of the message is that which she
+ explicitly arranges for. When Bob finishes processing the message,
+ he reports the outcome of the turn to no one.</p>
</li>
- <li>
- <p><i><a name="pipe-send"></a></i><b>The pipelined send</b>. When a
- send expression appears in a context where it is not statically apparent
- that the value of the send expression will be unused, ie, where static
- analysis does not rule out that the value may be used, such as on
+ <li>
+ <p><i><a name="pipe-send"></a></i><b>The pipelined send</b>. When a
+ send expression appears in a context where it is not statically apparent
+ that the value of the send expression will be unused, ie, where static
+ analysis does not rule out that the value may be used, such as on
the right side of a def:</p>
- <blockquote>
+ <blockquote>
<pre>def promise := bob <- foo(carol); </pre>
</blockquote>
<p><i><img src="images/send.gif" width="178" height="215" align="right"></i>then,
@@ -257,40 +257,40 @@
</li>
</ol>
<h2>Turning Control-Flow into Semi-Data-Flow</h2>
- <p>Since Ejectors are only dynamic in extent -- they only remain valid until
- their spawning escape expression completes -- the outcome of a turn cannot
- be an escape, only success or failure. Therefore, the Resolver only needs
- to respond to "<code>resolve(result)</code>" and "<code>smash(problem)</code>".
- In the first case, the promise becomes equivalent to <code>result</code>.
- In the second, the promise becomes broken, and problem is reported as
+ <p>Since Ejectors are only dynamic in extent -- they only remain valid until
+ their spawning escape expression completes -- the outcome of a turn cannot
+ be an escape, only success or failure. Therefore, the Resolver only needs
+ to respond to "<code>resolve(result)</code>" and "<code>smash(problem)</code>".
+ In the first case, the promise becomes equivalent to <code>result</code>.
+ In the second, the promise becomes broken, and problem is reported as
the reason. </p>
- <p>Assume that <code>brokenRef</code> is a reference broken with <code>problem</code>.
- Note that a stack-frame as continuation reacts differently to "resolve(brokenRef)"
- and "smash(problem)" -- the first causes successful evaluation
- to brokenRef while the second causes exceptional flow of control. On the
- other hand, A Resolver reacts to these two messages identically. As a
- result, Alice cannot distinguish between these two ways Bob may have reported
+ <p>Assume that <code>brokenRef</code> is a reference broken with <code>problem</code>.
+ Note that a stack-frame as continuation reacts differently to "resolve(brokenRef)"
+ and "smash(problem)" -- the first causes successful evaluation
+ to brokenRef while the second causes exceptional flow of control. On the
+ other hand, A Resolver reacts to these two messages identically. As a
+ result, Alice cannot distinguish between these two ways Bob may have reported
a problematic outcome.</p>
- <p align="left">All messages sent on a reference arrow move towards the
- arrowhead in order to eventually be delivered to the object pointed at.
- Messages sent on an unresolved promise do likewise, but wait behind the
- unbound arrowhead until the promise is resolved. Once the promise is resolved,
- all messages sent on the promise may now be delivered to this resolution.
- In the control-flow programming we started with the caller waits for the
- recipeint to be determined. By contrast, with <i>semi-data-flow</i> programming
- -- the message, not the sender, waits for the recipient to be determined.
+ <p align="left">All messages sent on a reference arrow move towards the
+ arrowhead in order to eventually be delivered to the object pointed at.
+ Messages sent on an unresolved promise do likewise, but wait behind the
+ unbound arrowhead until the promise is resolved. Once the promise is resolved,
+ all messages sent on the promise may now be delivered to this resolution.
+ In the control-flow programming we started with the caller waits for the
+ recipient to be determined. By contrast, with <i>semi-data-flow</i> programming
+ -- the message, not the sender, waits for the recipient to be determined.
</p>
- <p align="left">(We call this <i>semi-data-flow</i> to distinguish it from
- conventional data flow. In conventional data flow, a message would not
- be delivered until the recipient and all its arguments were resolved.
- This cannot be reconciled with E's partial ordering constraints, and is
- undesirable on other grounds as well. On those occasions where it is desired,
- it may easily be programmed in E. See the <code>promiseAllDone</code>
+ <p align="left">(We call this <i>semi-data-flow</i> to distinguish it from
+ conventional data flow. In conventional data flow, a message would not
+ be delivered until the recipient and all its arguments were resolved.
+ This cannot be reconciled with E's partial ordering constraints, and is
+ undesirable on other grounds as well. On those occasions where it is desired,
+ it may easily be programmed in E. See the <code>promiseAllDone</code>
(*** link needed) pattern.)</p>
<h2 align="left">Turning Semi-Data-Flow back into Control-Flow</h2>
- <p align="left">In our story so far, there is a puzzling contagion of eventual-ness.
- Once you have a reference that might be eventual, you must send rather
- than call on it; and when you do so, you get back another eventual reference
+ <p align="left">In our story so far, there is a puzzling contagion of eventual-ness.
+ Once you have a reference that might be eventual, you must send rather
+ than call on it; and when you do so, you get back another eventual reference
as a promise for the result.</p>
<h3 align="left">when-catch</h3>
<h3 align="left">whenResolved & whenMoreResolved</h3>
1.10 +5 -5 e/doc/elib/concurrency/partial-order.html
Index: partial-order.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/partial-order.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- partial-order.html 2001/05/07 08:29:25 1.9
+++ partial-order.html 2001/05/09 05:00:41 1.10
@@ -91,7 +91,7 @@
that reference to send message W to Carol, the happenstance of variable
network delays may result in W arriving before X. The reference
as handed to Bob gave Bob a dangerous possibility -- of delivering
- a message ahead of X -- that was beyonds Alice's notion of the reference's
+ a message ahead of X -- that was beyond Alice's notion of the reference's
meaning. This would be dangerous.</p>
<p>Instead, when a reference is included as an argument of an eventually
sent message (as Alice's reference to Carol is included in message
@@ -104,7 +104,7 @@
ordering guarantees E provides. The tree of messages connected by
a reference topology is the partial order itself. </p>
<p>As of any visualized state, the messages that may be delivered
- to Carol are those that have to messages ahead of them in the reference
+ to Carol are those that have no messages ahead of them in the reference
topology. In diagrams #1 and #2, this is only message X. The transition
to diagram #3 shows message X being delivered to Carol. Following
this, we see in diagram #3 that both messages W and Z are candidates
@@ -127,9 +127,9 @@
The implementation is free to deliver messages to Carol in any full order
consistent with the specified partial order. It can therefore collapse
partial orders to full orders whenever convenient, consistent with these
- constraints. As Bill Frantz observed, this one of those rare cases where
- the specification is much more "expensive" than the implementation.</p>
- <p>Although the motivation for these rules is correctness in the face or
+ constraints. As Bill Frantz observed, this is one of those rare cases
+ where the specification is much more "expensive" than the implementation.</p>
+ <p>Although the motivation for these rules is correctness in the face of
error, we do tighten the specification to deal with security in the face
of malice as well. Even if Bob is hosted in a tampered vat, VatB, that
doesn't "play by the rules", the protocol must constrain VatB
1.8 +2 -2 e/doc/elib/concurrency/semi-transparent.html
Index: semi-transparent.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/semi-transparent.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- semi-transparent.html 2001/04/14 19:56:57 1.7
+++ semi-transparent.html 2001/05/09 05:00:41 1.8
@@ -74,7 +74,7 @@
of Hewitt's Open Systems.</p>
<p><a href="http://www.sun.com/research/techrep/1994/abstract-29.html"><i><b>A
Note on Distributed Computing</b></i></a> argues, in effect, that the
- costs of these restriction are too high for general purpose distributed
+ costs of these restrictions are too high for general purpose distributed
computing. While we disagree with many of the particular arguments in
the paper, we find the conclusions phrased much too strongly, and we find
the above fully transparent systems much more plausible than this paper
@@ -229,7 +229,7 @@
<td>
<p><font size="+1">Synchronous <b>call</b>-return:</font></p>
<blockquote>
- <pre>val := bob msg(barol)</pre>
+ <pre>val := bob msg(carol)</pre>
</blockquote>
</td>
<td>
1.11 +19 -19 e/doc/elib/concurrency/turns.html
Index: turns.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/turns.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- turns.html 2001/04/14 19:56:57 1.10
+++ turns.html 2001/05/09 05:00:41 1.11
@@ -61,16 +61,16 @@
because of a sequence of turns, and each turn executes with mutually exclusive
access to this state, and it executes to completion before before the
next turn starts. </p>
- <p align="left">Although other Vats are executing concurrently, a caller
- will only see synchronous side effects caused by its callee. Because Vats
- are only asunchronously coupled to each other, an E turn implicitly has
- full mutual exclusion on all state to which it has synchronous access
- -- which is only state within its Vat. As a result, E execution is not
- observably distinguishable (except for timing and the effects of infinite
- loops) from an implementation in which, across the universe, only one
- Vat at a time takes a turn. E’s turns are therefore atomic serializable
- micro-transactions, and E is strongly consistency preserving in the face
- of concurrency, without any error-prone fine-grained locking.
+ <p align="left">Although other Vats are executing concurrently, a caller
+ will only see synchronous side effects caused by its callee. Because Vats
+ are only asynchronously coupled to each other, an E turn implicitly has
+ full mutual exclusion on all state to which it has synchronous access
+ -- which is only state within its Vat. As a result, E execution is not
+ observably distinguishable (except for timing and the effects of infinite
+ loops) from an implementation in which, across the universe, only one
+ Vat at a time takes a turn. E’s turns are therefore atomic serializable
+ micro-transactions, and E is strongly consistency preserving in the face
+ of concurrency, without any error-prone fine-grained locking.
<p align="left">We say <i>micro-transaction</i> above because we purposely
unbundle or avoid the features combined by the classic ACID transaction:
<p align="left">
@@ -138,15 +138,15 @@
observable variable’s assigner returned from the assignment. The code
containing the assignment was likely written without taking the possibility
of such side effects in mind, and this is as it should be.
- <p align="left">When Alice passes a message to Bob in order to subcontract
- part of her plan to Bob, she is invoking Bob on her own behalf, and so
- would often want to wait for Bob’s side effects and outcome. The immediate
- call does precisely this. When Alice passes a message to Bob on Bob’s
- behalf, as when Alice is an observable and Bob is an observer, this courtesy
- provided to Bob should be minimally disruptive to Alice. The send above
- queues, on the queue of the observer's vat, a pending delivery of a <code>valueChanged()</code>
- message to this observer. This delivery will happen in its own separate
- turn, and cannot effect the turn from which it was sent.
+ <p align="left">When Alice passes a message to Bob in order to subcontract
+ part of her plan to Bob, she is invoking Bob on her own behalf, and so
+ would often want to wait for Bob’s side effects and outcome. The immediate
+ call does precisely this. When Alice passes a message to Bob on Bob’s
+ behalf, as when Alice is an observable and Bob is an observer, this courtesy
+ provided to Bob should be minimally disruptive to Alice. The send above
+ queues, on the queue of the observer's vat, a pending delivery of a <code>valueChanged()</code>
+ message to this observer. This delivery will happen in its own separate
+ turn, and cannot affect the turn from which it was sent.
<p align="left">We can now understand why the other peculiar thing in the
above code is harmless: To illustrate our point, we put the actual assignment
after the loop notifying the observers. If we were calling the observers
1.35 +14 -15 e/doc/elib/concurrency/vat.html
Index: vat.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/vat.html,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- vat.html 2001/05/05 23:47:00 1.34
+++ vat.html 2001/05/09 05:00:41 1.35
@@ -101,12 +101,12 @@
a NEAR (green) reference to a copy of this 3 in his own Vat.</p>
</li>
</ul>
- <p ALIGN="left">Each Vat executes concurrently with all other Vats, but
- there is no concurrent execution within a Vat. In this sense, a Vat is
- vaguely like a traditional OS process -- it bundles together of a single
- thread of control and an address space of synchronously accessible data,
- and so avoids the need for bug-prone fine-grained locking on this data.
- Unlike a traditional OS process, a Vat’s thread is necessarily a non-blocking
+ <p ALIGN="left">Each Vat executes concurrently with all other Vats, but
+ there is no concurrent execution within a Vat. In this sense, a Vat is
+ vaguely like a traditional OS process -- it bundles together a single
+ thread of control and an address space of synchronously accessible data,
+ and so avoids the need for bug-prone fine-grained locking on this data.
+ Unlike a traditional OS process, a Vat’s thread is necessarily a non-blocking
event loop servicing a queue of pending deliveries. </p>
<P ALIGN="left">Each <i>pending delivery</i> is a pair of a message and
a recipient to whom it should be delivered. Each time around the loop,
@@ -119,15 +119,14 @@
<li><a href="turns.html">Game Turns as MicroTransactions</a> explains
the strong atomicity properties provided by E, simply, and without explicit
locking or mutual exclusion constructs. </li>
- </ul>Within a Vat we have a mostly-traditional world of sequential
- call-return object programming, which we call Local-E. Between Vats we
- only have asynchronous non-blocking message sending: the stubby blue arrow
- above is a message transmitted between Vats (whose security provided by
- E’s cryptographic implementation of distributed capabilities). When received
- by the recipient’s hosting Vat, it will be queued on this Vat’s queue
- as a pending delivery of this message to this recipient, to be processes
- in its own turn.
- <!-- #EndEditable --></TD>
+ </ul>
+ Within a Vat we have a mostly-traditional world of sequential call-return
+ object programming, which we call Local-E. Between Vats we only have asynchronous
+ non-blocking message sending: the stubby blue arrow above is a message transmitted
+ between Vats (whose security is provided by E’s cryptographic implementation
+ of distributed capabilities). When received by the recipient’s hosting Vat,
+ it will be queued on this Vat’s queue as a pending delivery of this message
+ to this recipient, to be processed in its own turn. <!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
<TR VALIGN="TOP">
1.7 +1 -1 e/doc/elib/distrib/obj-passing.html
Index: obj-passing.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/obj-passing.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- obj-passing.html 2001/05/07 08:29:25 1.6
+++ obj-passing.html 2001/05/09 05:00:42 1.7
@@ -57,7 +57,7 @@
<h1>PassByConstruction</h1>
<p>When a PassByConstruction object is passed between vats, it causes an
object to be constructed in the remote vat as its remote <i>presence</i>.
- PassByConstruction objects are shown as rectangles in our extended Grannovetter
+ PassByConstruction objects are shown as rectangles in our extended Granovetter
notation. </p>
<p>These presences taken together <i>are</i> the PassByConstruction object
as a whole, and the original object is simply the originating presence.