On Sat, Sep 16, 2023, 2:33 PM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
Dmitry Gutov <dmitry@gutov.dev> writes:

> On 16/09/2023 20:07, Gerd Möllmann wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>>
>>> On 16/09/2023 17:20, Björn Bidar wrote:
>>>> These more extensive modes require more advanced features similar as
>>>> when turning Emacs into a "word processor".
>>>> In my opinion Emacs being single threaded is the biggest hurdle in that,
>>>> gui lockup is the biggest no no in regular gui apps.
>>> JavaScript is single-threaded.
>>>
>>> They have a certain solution for parallelism in specific workloads,
>>> though (called Web Workers).
>> In Emacs, GC can run Lisp I'm told (finalizers), regexp matching can
>> definitely run Lisp (bug#58042), and the devil knows what else 🙁.  I
>> personally have no idea how it would be possible to untangle this for a
>> multi-threaded Lisp.
>
> Each Web Worker (in JS) uses a separate address space, without sharing
> references, exchanging information through "messages" (which are
> copied, not shared).

Yes, that's what I gathered from reading about web workers on the web.
Do you know what, if anything, makes JS single-threaded?

> So this would be like parallel Lisp interpreters with separate
> obarrays, memory spaces, etc.

Which means someone has to "modularize" the current C code, so that, for
example, more than one GC module, Interpreter module, etc. could exist.

Not easy, but in my eyes, it would definitely be an improvement.  Is
there someone already working in this direction?

(Not that anyone gets thei mpression I'd work on this...  Just saying
:-).

I've mentioned before that multithreading should be split into (same process) multi-lisp-cpu multiprocessing and same lisp CPU multithreading.  It's on my agenda, but there's a lot of lower hanging fruit/prerequisites to do first.

Lynn