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.
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).
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.
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.
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.
eRef doSomethingNonReadOnly whenResolved: [:r | eRef resolve: ???].
"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?"
< #ClassType !! <ClassName !! ASN1UTF8String !! Exportable {true|false}>> !! <IVarRecords !! #SequenceOfIVarRecord !! <IVarRecord !! IVarName !! ClassTypeName !! ASN1Type>> !! <MethodRecords !! #SequenceOfMethodRecord !! <#MethodRecord !! MethodName !! ReturnClassTypeName !! ReadOnly !! RequiresTransaction>
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.
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.
Best, • rabbit ❤️🔥🐰
On 8/20/23 18:40, Martin McClure via Cuis-dev 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
-- ••• rabbit ❤️🔥🐰