[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs design and architecture

From: Gerd Möllmann
Subject: Re: Emacs design and architecture
Date: Sat, 16 Sep 2023 20:33:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]