Re: Emacs design and architecture

[Gerd Möllmann]

Dmitry Gutov <dmitry@gutov.dev> writes:

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

Yes, thanks, that was what I meant.

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

Yes, that's of course also a "solution" - add a second
language/VM/runtime or runtime to Lisp.  It at least avoids untangling
Emacs' C code :-).

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

Hm.