<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
<body>
<p>Thank you, Martin. It has been several days since I was running
Squeak, which is where I do all my development, accessing the
Cryptography repo on SqueakSource. <br/>
</p>
<p>Allow me to explain the ways in which I am thinking about this
multi-threaded model. I AM looking to do shared state. However, I
will provide handled eventual referendces, such that only 1 thread
would be able to write. All writes by the 1 owner Kitty (my name
to the each threaded event-loop). <br/>
</p>
<p>All other local Kitties will have a handled Neighbor reference. A
Neighbor reference would allow immediate reads, but any writes
would get sent to the owner Kitty, and perhaps flip the
Neighbor-local reference to a Promise to queue reads until the
write is done. <br/>
</p>
<p>In order to accomplish this, we need to know which methods result
in writes. It's not just a setter method, but any action methods
that call a setter or assign the the ivar. I plan to generate
proxy methods on the Spectre class for the RemoteRef to a
particular class. Type info. The ClassType I imagine would include
whether the method is read-only or not. For methods that are
read-only, generate Spectre methods that do immediate
shared-memory access to the state.</p>
<p>For methods which are not red-only, generate method that forwards
the send to the Near in the owner Kitty and potentially flip the
Neighbor to a NearPromise, inside the generated #doSomethingNonReadOnly)
for send queuing until the promise of the non read-only send
resolves (#whenResolved:) to send these queued methods and resolve
the ref promise. So 2 promises: 1 for the send and 1 for the ref.</p>
<blockquote>
<p>eRef doSomethingNonReadOnly<br/>
whenResolved: [:r | eRef resolve: ???].</p>
<p>"hmmm...how to preserve the original eRef for resolving the
temp promise of it? I use #becomeForward: so the original eRef
is gone. We need a special NearPromise that somehow preserves
the original eRef, even under #becomeForward:, as the eRef is
not necessarily the return of #doSomethingNonReadOnly. Huh?"<br/>
</p>
</blockquote>
<p><<br/>
#ClassType<br/>
!! <ClassName<br/>
!! ASN1UTF8String<br/>
!! Exportable {true|false}>><br/>
!! <IVarRecords <br/>
!! #SequenceOfIVarRecord <br/>
!! <IVarRecord<br/>
!! IVarName<br/>
!! ClassTypeName<br/>
!! ASN1Type>><br/>
!! <MethodRecords<br/>
!! #SequenceOfMethodRecord<br/>
!! <#MethodRecord<br/>
!! MethodName<br/>
!! ReturnClassTypeName<br/>
!! ReadOnly<br/>
!! RequiresTransaction><br/>
><br/>
></p>
<p>We can use a parser to try and detect writes. Also, as these
shared objects would be #beReadOnlyObject, except when the owner
Kitty is running a write method, then any ModificationException
would update the Read-Only mark of that method in its ClassType.
Or something.</p>
<p>To summarize to you, Martin, in a salient, I am looking to
establish safe shared-memory access. I definitely would like to
see a new Morphic that was multi-threaded (Eventual). Each Kitty
could run on a separate native thread.</p>
<p>Best,<br/>
• rabbit ❤️🔥🐰<br/>
</p>
<div class="moz-cite-prefix">On 8/20/23 18:40, Martin McClure via
Cuis-dev wrote:<br/>
</div>
<blockquote type="cite" cite="mid:1606571d-63a1-83ea-0545-bdad0d42bcc8@hand2mouse.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<div class="moz-cite-prefix">Hi Szabolcs,<br/>
<br/>
An interesting question. I'm a bit late to this discussion, but
your comments touch on a topic that has interested me for many
years, so I'd like to take a step back and examine the question
a bit more (partially duplicating what others have already said,
alas).<br/>
<br/>
Systems with multiple threads of execution can be divided into
two primary categories: Those where the threads share memory
(now usually called threads) and those where each thread
operates in its own memory (now usually called processes).<br/>
<br/>
In the 1970s, when Smalltalk was being designed, this
distinction was not yet standard, and so Smalltalk has class
Process, which now would be called Thread.<br/>
<br/>
A system where each process has its own memory can be very
successful, as most modern operating systems demonstrate.<br/>
<br/>
Shared-state multi-threading, for all that it's widely used,
turns out to be a <i>terrible</i> idea. Very simple uses can be
"thread-safe," but anything that even starts to be complex makes
correctness so unlikely that it might as well be impossible. But
this was another thing not known in the 1970s, so that's how
Smalltalk was designed. Making Smalltalk thread-safe was
something that I advocated for quite some years, until I
realized that it was essentially impossible.<br/>
<br/>
Better solutions exist in more recent languages like E, and even
more recent languages like Dart that take ideas from E. In E,
each thread runs in its own object space, so it's more like OS
processes. There are, as you'd expect, ways to send messages
asynchronously between processes. It appears to be much easier
to make a correct multi-threaded program this way.<br/>
<br/>
I was also frustrated by the 1984 Mac OS. I think they might
have been better off with a preemptive multitasking system at
that time. It wouldn't have been difficult to write one -- I
wrote one for 8-bit processors in 1982-1983 that could run
independent or cooperating processes within the same processor
or across multiple processors. Apple was stuck with the
implications of that design for fifteen years. But maybe their
choice was justified -- my OS would have run into memory
fragmentation issues if stressed hard, and the original Mac was
<i>so</i> short on memory for what it tried to do. Ah, well,
it's all history now.<br/>
<br/>
In summary, I think trying to convert Smalltalk to a
"thread-safe" multi-threaded design with shared state would be
very hard. Worse, it is an undesirable goal, because modifying
such a system without introducing race conditions or deadlocks
would be very very hard, and would sacrifice Smalltalk's
flexibility. But extending Smalltalk into a multi-threaded
system where each thread has its own object space is more
achievable, and a better goal. I get the impression that this
sort of thing is what Rabbit is up to.<br/>
<br/>
Regards,<br/>
-Martin<br/>
<br/>
<br/>
On 8/15/23 12:18, Szabolcs Komáromi via Cuis-dev wrote:<br/>
</div>
<blockquote type="cite" cite="mid:82cba8f9-0ce8-4fd5-a6e6-b9303968416c@app.fastmail.com">
<div>Hi Juan, Ken,<br/>
</div>
<div><br/>
</div>
<div>Thanks for the explanation. I'm constantly confused, at
least for the time being, by the dichotomy of Smalltalk's
"operating systemness" and its implementation as an
application. <br/>
</div>
<div><br/>
</div>
<div>If Smalltalk would be an operating system it would be
normal to have multiple GUI-threads. But Smalltalk is an
application thus it is perfectly normal to have only one
GUI-thread. If i understand correctly.<br/>
</div>
<div><br/>
</div>
<div>I'm currently reading John Maloney's papers about Morphic
to better understand what Morphic is. If I'm correct Morphic
at its core is an abstract idea about a GUI framework that
emphasizes concreteness, liveness, and uniformity. <br/>
</div>
<div><br/>
</div>
<div>When I asked my question what was in my mind is Apple's
struggle with QuickDraw and the classic Mac OS's basic design
what prohibited preemptive multitasking during the 1990s. I
thought maybe there is something similar about Morphic. A
somewhat better question would have been whether Cuis' Morphic
implementation is inherently not tread safe or every possible
implementation of Morphic wouldn't be be thread safe. But this
is also a silly question if Morphic is an abstract idea. <br/>
</div>
<div><br/>
</div>
<div>Regards,<br/>
</div>
<div>Szabolcs<br/>
</div>
<div><br/>
</div>
</blockquote>
<br/>
</blockquote>
<pre class="moz-signature" cols="72">--
••• rabbit ❤️🔥🐰</pre>
</body></html>