[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Native thread support
Re: Native thread support
Mon, 14 Feb 2022 20:31:11 +0000
mu4e 1.7.5; emacs 27.2
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
Andreas Rosenberg <firstname.lastname@example.org> writes:
> 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
> so I hardly see any reason, why anybody would invest in such a project.
> Best regards,
> On 05.02.2022 21:09, Blake McBride wrote:
>> 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.
>> Blake McBride