[Top][All Lists]

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

Re: Emacs design and architecture

From: Dmitry Gutov
Subject: Re: Emacs design and architecture
Date: Sat, 16 Sep 2023 22:40:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 16/09/2023 21:33, Gerd Möllmann 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?

I'm not sure if I understand the question, but to my knowledge, it uses the same kind of "interpreter lock" as is common in other "interpreted" languages too (Ruby, Python, PHP, Lua).

That's not the whole story, though, because it's a lock within the "interpreter context", and every open tab has its own. Most tab do not interact in any way, cannot access each other's data, so it's fine to run their JS code in parallel. Likewise, JS on the web doesn't have any access to the browser chrome, meaning they're fine to run in parallel too. In fact, modern browsers run several processes: one for the UI and several for the browser tabs (last info I saw on this, link below, is that Chrome used a process-per-tab, and Firefox combined several tabs in one process using parallel threads).


This is already more parallelism than we have (each piece of our code can access everything), but OTOH they have more spinning plates at the same time.

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

The best I can point to are comments on Reddit around when emacs-ng launched: https://www.reddit.com/r/emacs/comments/kmh9k1/comment/ghm68j2/

It included the ability to run code in Deno's Web Workers. It feels like something that would help with some existing problems (e.g. parting JSON in a worker, extracting a subpath from it and sending the result to the parent process), but I don't remember reading any serious code done with it. Possibly just because all big packages have to keep compatibility with the GNU version anyway, so I'm hopeful about such prospects if we ever even get a prototype in GNU Emacs. At the very least, it can be like a faster async.el, with all of its existing use cases.

reply via email to

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