<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thanks for sharing that Martian. I wasn’t aware of E existence. I’m curious that’s why also self is a single process because it had thread safe issues at the development stage. <br><br><div dir="ltr">Regards,</div><div dir="ltr"><br></div><div dir="ltr">Joseph Turcio</div><div dir="ltr"><br><blockquote type="cite">On Aug 20, 2023, at 6:40 PM, Martin McClure via Cuis-dev <cuis-dev@lists.cuis.st> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<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>
<span>-- </span><br><span>Cuis-dev mailing list</span><br><span>Cuis-dev@lists.cuis.st</span><br><span>https://lists.cuis.st/mailman/listinfo/cuis-dev</span><br></div></blockquote></body></html>