[squeak-dev] Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)

Robert Withers robert.withers at pm.me
Sat Sep 26 01:42:14 UTC 2020


Hi Tony, I am excited to conversate with you, regarding Promises. Vollständig geil!

Von: Tony Garnock-Jones [<tonyg at leastfixedpoint.com>](mailto:tonyg at leastfixedpoint.com)

> Gesendet: Freitag, 25. September 2020 16:55:23
> An: The general-purpose Squeak developers list; Thiede, Christoph
> Betreff: Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)
> Hi Christoph,
>
> On 9/24/20 2:08 PM, Thiede, Christoph wrote:
>>> It's true that in Morphic there is one distinct Process associated
>> with the user interface for each Morphic world.
>>
>> I'm not so sure about this. You can always do forks within UI code, so
>> sometimes there are also multiple Processes within one Morphic world.
>> Just think about Shout's background process or debugging processes, and
>> please keep in mind that Jakob justifiably proposed to renew the process
>> handling for non-modal dialogs, which maybe could also result in
>> multiple processes being active at the same time.
>> A world can have multiple hands, for example, RemoteHandMorphs
>> (Nebraska), event-simulating hands (EventRecorder), or just
>> multiple plain HandMorphs as demonstrated by Tony recently in
>> his PostmarketOS implementation. There is no reason for these hands to
>> run on the same process. Analogously, I don't see why we should restrict
>> a hand not to be thread-safe, so the hand-event relation is 1:n again.
>
> I've found that while, yes, there are lots of opportunities for
> concurrency in Morphic, actually *taking* those opportunities results in
> all sorts of problems.
>
> Morphic state is I think not thread-safe enough to allow multiple
> processes "inside" of it at once.
>
> So I've ended up being *very* careful to serialize all Morphic access
> within the one, main UI process. Where other processes (Actors) exist, I
> send messages from the UI process to the others, and when Morphic state
> change code has to run, I package it up into a block and enqueue it for
> later execution by the UI process rather than doing it in each Actor.
>
> (It's painful, actually, having to be so careful about it, in such a
> C-style "you do all the work yourself and the system won't help you"
> manner. Maybe there's something we can improve here?)
>
> So I think it's *morally* true that "there is one distinct Process
> associated with the user interface for each Morphic world," even if as a
> rule it can be bent a little :-)

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.

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.

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:).

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!

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.

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, vollständig geil!

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.

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]. It's core is the EventualProcess running contexts, as the Vat pumps them in priority [#1-#4] order.

[1] Galaxy Object Scenario - https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20repaired.pdf?dl=0
[2] PPS - PromisePipeliningProgrammingStyle

Kindly,
Robert

> Cheers,
> Tony

--
K, r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200926/74111bc8/attachment.html>


More information about the Squeak-dev mailing list