[Cuis-dev] Morphic's design

[Martin McClure]

Hi Szabolcs,

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

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

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.

A system where each process has its own memory can be very successful, 
as most modern operating systems demonstrate.

Shared-state multi-threading, for all that it's widely used, turns out 
to be a /terrible/ 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.

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.

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 /so/ 
short on memory for what it tried to do. Ah, well, it's all history now.

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.

Regards,
-Martin


On 8/15/23 12:18, Szabolcs Komáromi via Cuis-dev wrote:
> Hi Juan, Ken,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
> Szabolcs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230820/ec0f15ba/attachment.htm>