<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Yes, Tony, usually, I like to use deferred UI messages, too. :-) But when designing such a low-level construct such as ActiveEvent, I think it's better to expect every eventuality, isn't it?</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Tony Garnock-Jones <tonyg@leastfixedpoint.com><br>
<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>
<br>
Cheers,<br>
Tony<br>
</div>
</span></font>
</body>
</html>