It's a downward spiral - with 8 Core chips becoming normal, and servers with 96 and upward, the appeal of a single-threaded language declines every year, so the chance of someone investing in it decreases, so the appeal decreases....
Such is life. Smalltalk MT appears to have had multi-threading but the modifications needed changed debugging radically (I read), and the system is Windows-only. There was also the Roar VM for Squeak, which was multi-core (https://github.com/smarr/RoarVM#roarvm---the-manycore-squeakvm) but it's now 9 years since it was updated. Still might be worth a look. It is frustrating as the Smalltalk model of programming would seem at first look to be ideal for multi-threading: individual computing objects each pining messages to each other and then responding, like a cloud of VMs where each little VM is one instance of a class. The usual response to questions about multi-threading involve running multiple Smalltalks and letting them communicate via the OS in some way, which is almost exactly this model. Which begs the question: if the VMs can talk to each other using the OS, why can't they talk to eachother directly in Smalltalk? If I ever win the lottery, we will get answers to these questions and many more :D Thomas Andreas Rosenberg <andreas_rosenb...@web.de> writes: > Greetings, > > just a few thoughts regarding multi-threading support. In my job, I'm > maintaining the > VM source code of the Digitalk Smalltalk VM. I have made some > considerations how > Smalltalk could support native multi-threading and there are a lot of > hurdles to overcome: > > - the garbage collector: also a multi-threaded garbage collector is > required, which is quite > complex. Each thread needs at least it's own "short term object > heap". Even in Java a full GC > requires a "world stop" and each thread must have reached a so called > "safe point" to make > a full GC work. This requires special means of synchronization for > each thread. > > - the language needs new keywords to deal with synchronization issues. > > - many base classes must be rewritten to be thread safe > > - probably a lot of other problems may exist, that are not visible in > the first place > > To my knowledge currently no Smalltalk implementation exists, which can > do multi-threading. > The basic design was done in the 70ties and early 80ties and > multi-threading has not > been considered during that era. > > Afaik only Java and C# have a VM that supports automatic garbage > collection with multiple native > threads. I don't know about C#, but the team working on JDK is about 580 > people (at least > this is number of different committers on the github project). > Imho a considerable effort is needed, which would only be done, if there > is a "strong need" > and a team of clever people who might achieve this. > > Smalltalk is only a niche system and the user base is declining more and > more, > so I hardly see any reason, why anybody would invest in such a project. > > Best regards, > > Andreas > > On 05.02.2022 21:09, Blake McBride wrote: >> Greetings, >> >> One of the things that have kept me from all Smalltalks is the lack of >> true/native multi-threading support that is able to utilize multiple CPUs. >> In today's world, it is a show-stopper for me and many others. >> >> I believe that GST only supports cooperative threads utilizing a single >> machine thread. Adding true native thread support would make GST quite >> appealing to a large crowd IMO. I'd also guess that adding said support >> would be difficult but easier in GST than other Smalltalks. >> >> Just a thought. >> >> Thanks! >> >> Blake McBride
