[Cuis-dev] Morphic's design

[Joseph Turco]

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. 

Regards,

Joseph Turcio

> On Aug 20, 2023, at 6:40 PM, Martin McClure via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
> 
> 
> 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
>> 
> 
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230821/9fe4216c/attachment.htm>