<html><head></head><body>
<p>My current #RED code in progress to these ends are:</p>
<p><a class="moz-txt-link-freetext" href="http://www.squeaksource.com/Oceanside/PromisesLocal-rww.12.mcz">http://www.squeaksource.com/Oceanside/PromisesLocal-rww.12.mcz</a> <br/>
</p>
<p><a class="moz-txt-link-freetext" href="http://www.squeaksource.com/Oceanside/PromisesLocal-KernelTests-rww.383.mcz">http://www.squeaksource.com/Oceanside/PromisesLocal-KernelTests-rww.383.mcz</a>
<br/>
</p>
<p>K, r<br/>
</p>
<div class="moz-cite-prefix">On 9/25/20 9:42 PM, Robert Withers
wrote:<br/>
</div>
<blockquote type="cite" cite="mid:1013fa15-717b-71bb-e6b3-d9ecae8a08c0@pm.me">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<p>Hi Tony, I am excited to conversate with you, regarding
Promises. <i><b>Vollständig</b></i><i><b> geil!</b></i><br/>
</p>
<font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>Von:</b> Tony Garnock-Jones <a class="moz-txt-link-rfc2396E" href="mailto:tonyg@leastfixedpoint.com" moz-do-not-send="true"><tonyg@leastfixedpoint.com></a></font><br/>
<blockquote type="cite" cite="mid:ac8415e5cf6a450da5bc333a2063e47c@student.hpi.uni-potsdam.de">
<div dir="ltr">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"> <b>Gesendet:</b> Freitag, 25. September
2020 16:55:23<br/>
<b>An:</b> The general-purpose Squeak developers list;
Thiede, Christoph<br/>
<b>Betreff:</b> Multiple processes and morphic state (was
Re: Changeset: Eliminating global state from Morphic)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Christoph,<br/>
<br/>
On 9/24/20 2:08 PM, Thiede, Christoph wrote:<br/>
>> It's true that in Morphic there is one distinct
Process associated<br/>
> with the user interface for each Morphic world.<br/>
> <br/>
> I'm not so sure about this. You can always do forks
within UI code, so<br/>
> sometimes there are also multiple Processes within
one Morphic world.<br/>
> Just think about Shout's background process
or debugging processes, and<br/>
> please keep in mind that Jakob justifiably proposed
to renew the process<br/>
> handling for non-modal dialogs, which maybe could
also result in<br/>
> multiple processes being active at the same time.<br/>
> A world can have multiple hands, for example,
RemoteHandMorphs<br/>
> (Nebraska), event-simulating hands (EventRecorder),
or just<br/>
> multiple plain HandMorphs as demonstrated by Tony
recently in<br/>
> his PostmarketOS implementation. There is no reason
for these hands to<br/>
> run on the same process. Analogously, I don't see why
we should restrict<br/>
> a hand not to be thread-safe, so the hand-event
relation is 1:n again.<br/>
<br/>
I've found that while, yes, there are lots of
opportunities for<br/>
concurrency in Morphic, actually *taking* those
opportunities results in<br/>
all sorts of problems.<br/>
<br/>
Morphic state is I think not thread-safe enough to allow
multiple<br/>
processes "inside" of it at once.<br/>
<br/>
So I've ended up being *very* careful to serialize all
Morphic access<br/>
within the one, main UI process. Where other processes
(Actors) exist, I<br/>
send messages from the UI process to the others, and when
Morphic state<br/>
change code has to run, I package it up into a block and
enqueue it for<br/>
later execution by the UI process rather than doing it in
each Actor.<br/>
<br/>
(It's painful, actually, having to be so careful about it,
in such a<br/>
C-style "you do all the work yourself and the system won't
help you"<br/>
manner. Maybe there's something we can improve here?)<br/>
<br/>
So I think it's *morally* true that "there is one distinct
Process<br/>
associated with the user interface for each Morphic
world," even if as a<br/>
rule it can be bent a little :-)<br/>
</div>
</span></font></blockquote>
<p><font size="2">This would be sa-super spot to put a Vat,
running an event loop, with a proscribed way to submit a new
context through its queue.</font></p>
<p><font size="2">I have gotten super-lazy about it, am watching
Jen Aniston's show The Morning Show and other avoidance
behaviors (Totally Awsome!). I am halfway through getting
tests to work. <br/>
</font></p>
<p><font size="2">I maybe 65% there in porting ELibs PromisesLocal
as the implementation behind your Promise/A* protocol
interface. The main issue is your Promise can immediately
resolve to a value, whereas ELibs event loop has to process
the resolution async, so many tests need a small delay to
allow the Promise to resolve and process its traffic
(#whenResolved:). <br/>
</font></p>
<p><font size="2">I am having some trouble with figuring out my
own process architecture and services. I believe I have the
event loop restarting if it blows up, but with a loop guard
requiring a #running state (#stopping isFalse). I believe I am
passing Halts up the stack. I am trying to reschedule the
context copy through the vat, when a VatSemaphore is signaled.
Trying to create a pool of event pending contexts to get
rescheduled so, my efforts are not quite right and it is
Process/Exception handling. Extremely complicated for Noobs. I
am unsure!<br/>
</font></p>
<p><font size="2">My plan was to port PromisesLocal over and onto
and get all the PromiseTests tests running. As I was needing
to modify them for the async resolution, I was going to get
them all passing, then unload the PromisesLocal and verify the
Kernel-Tests work in the updated trunk. Then publish the Tests
to the Inbox, would be my first time! Make sure all is
coebatany, then publish PromisesLocal for considerations of
bringing that ELib model into trunk Squeak, with all of its
corresponding PromisesLocal Tests #Green. <br/>
</font></p>
<p><font size="2">I am proposing a deep change, in an area you
developed and extended into your Actors model. It underlies a
greeat work orf yours, so geil to always see happening in
Squeak!!! Again, </font><font size="2"><i><b>vollständig</b></i><i><b>
geil!</b></i></font></p>
<p><font size="2"> My PromisesRemote brings a remote messaging
solution. I am unsure whether your Promises or Actors are
remote aware. PromisesRemote are #green (aside from 3-way and
the Galaxy Object Scenario [1] being broken). Its core are the
proxy references that mutate through their state, forwarding
all traffic, at the right time.<br/>
</font></p>
<p><font size="2">Speaking of only PromisesLocal, as to her
ability to reimplement your Promise; having a Resolver object
is powerful and a good place to control the manner in which a
value manifests. All activity outgoing or incoming is
interleaved through the Vat's priority queues. It is a strong
guarantee of thread-safe activity. The #becoming of Promises
into References or Broken, is an interesting feature that
really helps one chain pipelined promises, is PPPS [2]. </font><font size="2"><font size="2">It's core is the EventualProcess
running contexts, as the Vat pumps them in priority [#1-#4]
order.</font></font></p>
<p><font size="2">[1] Galaxy Object Scenario -
<a class="moz-txt-link-freetext" href="https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20repaired.pdf?dl=0" moz-do-not-send="true">https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20repaired.pdf?dl=0</a><br/>
[2] PPS - PromisePipeliningProgrammingStyle</font></p>
<p><font size="2">Kindly,<br/>
Robert<br/>
</font></p>
<blockquote type="cite" cite="mid:ac8415e5cf6a450da5bc333a2063e47c@student.hpi.uni-potsdam.de"><font size="2"><span style="font-size:10pt;">
<div class="PlainText"> <br/>
Cheers,<br/>
Tony<br/>
</div>
</span></font> </blockquote>
<div class="moz-signature">-- <br/>
K, r<br/>
</div>
</blockquote>
<div class="moz-signature">-- <br/>
K, r<br/>
</div>
</body></html>