<html><head></head><body>
<p>Hi Jakob, <br/>
</p>
<p>I always want to assume best intentions, so I apologize for being
somewhat snarky in my last post. I am not offended nor am I mad at
you. Please don't be with me. <br/>
</p>
<div class="moz-cite-prefix">On 7/23/20 2:00 PM, Robert Withers
wrote:<br/>
</div>
<blockquote type="cite" cite="mid:5729379a-9559-e8c7-1233-218e18353293@pm.me">
<p>I have asked you several times to comment on the Promise
implementation in PromisesLocal, but you have not responded. <br/>
</p>
<blockquote>
<p>Installer ss project: 'Cryptography'; install:
'PromisesLocal'.</p>
</blockquote>
</blockquote>
<p>In consideration of my promises, I realize you may not understand
what I am proposing with the PromisesLocal package. It is a robust
amount of functional code. PromisesLocal attempts to be a working
implementation of the behaviors from ERights' ELib Concurrency
[1], which predates Mark Miller's joining Google Research for the
new JavaScript standard with his Promises/A+. I believe now that
the differences between the Promise in Kernel-Proccesses and
PromisesLocal is that PromisesLocal solves the concurrency issues,
with its concurrency model. Read about this here:<br/>
</p>
<p>[1] ELib's concurrency -
<a class="moz-txt-link-freetext" href="http://www.erights.org/elib/concurrency/index.html">http://www.erights.org/elib/concurrency/index.html</a></p>
<p>So allow me to demonstrate the outcomes of using PromisesLocal. <br/>
</p>
<p>First image, taking a look at the Workspace, in the lower left
above the Transcript, we have a good send, an exception send, and
then another good send, demonstrating that the event loop does not
get blocked. The first and last explorers resolve to 420. The
middle explorer becomes a BrokenERef, due to the ZeroDivide. As
well there is a debugger open for this exception, opened on a
stack copy of the signaler context. The event loop continues to
run but we have another process opened in the debugger. <br/>
<br/>
For this debugger logic, please see <br/>
</p>
<p><code>StandardToolSet class>>debugEventualException:
anException</code><code><br/>
</code><code> "For convenience. Construct a helper process to
debug an exception that occurred in the active process later on
so that the active process can (try to) resume. Uses a temporary
variable to access and copy the signaler context now before it
gets GC'ed."</code><code><br/>
</code><code> </code><code><br/>
</code><code> | helperProcess |</code><code><br/>
</code><code> helperProcess := (EventualProcess</code><code><br/>
</code><code> forContext: anException signalerContext
copyStack</code><code><br/>
</code><code> priority: Processor activeProcess priority</code><code><br/>
</code><code> onVat: Processor activeProcess vat)</code><code><br/>
</code><code> shouldResumeFromDebugger: true;</code><code><br/>
</code><code> yourself.</code><code><br/>
</code><code><br/>
</code><code> Project current addDeferredUIMessage: [</code><code><br/>
</code><code> helperProcess</code><code><br/>
</code><code> debugWithTitle: anException description</code><code><br/>
</code><code> full: false].</code><br/>
</p>
<p>I am calling this in EventualMessageSend>>#value if an
exception occurs during the send.<br/>
</p>
<img moz-do-not-send="false" src="cid:part1.B494C77A.601CE0D5@pm.me" alt="" width="1158" height="518"/>
<p>Second image is of the situation after proceeding from the
Debugger and then running the first line a second time, getting
another NearERef of 42. The event-loop is active.<br/>
</p>
<img moz-do-not-send="false" src="cid:part2.F1CB4647.908D4FCA@pm.me" alt="" width="1162" height="520"/>
<p>The third image demonstrates the PriorityVat running
#nextProcessMsg (the event loop!) as well as another process for
the ZeroDivide exception and its copied stack.<br/>
</p>
<p><img moz-do-not-send="false" src="cid:part3.A2320E4D.B50EFB0F@pm.me" alt="" width="1161" height="744"/></p>
<p>Finally, allow me to add a halt in the Vat's machinery to halt
when an exception is handled in EventualMessageSend>>#value,
this will halt on the ZeroDivide, after resolving the promise to
broken, but before the stack copy of the signalerContext. This is
before the helperProcess is made, so we see in the Processes there
is the event loop open in the debugger (look for the process with
a priority of 30). As this broke before the last item in the
normalQ of the vat, the last explorer still shows a Promise. The
event loop is blocked. When the Debugger is resumed or abandoned,
the event loop DIES a quiet death, so we must clear it an restart
the #local Vat, to regain operability, thus the new first line in
the Workspace. I believe that adding a strategic call to
#ifCurtailed: would be helpful here, to restart the Vat. i am
unsure where to put this call.<br/>
</p>
<p><img moz-do-not-send="false" src="cid:part4.4ACAC70E.459BE891@pm.me" alt="" width="1058" height="652"/></p>
<p>I hope the workspace examples give you more familiarity of use
and these images show what is actually happening with
PromisesLocal.</p>
<p>Kindly,<br/>
rabbit<br/>
</p>
<br/>
</body></html>