<html><head></head><body>
<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"><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">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>
</body></html>