Re: Emacs design and architecture

[Dmitry Gutov <dmitry@gutov.dev>]

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).

https://medium.com/mozilla-tech/the-search-for-the-goldilocks-browser-and-why-firefox-may-be-just-right-for-you-1f520506aa35

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.