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