Re: Emacs design and architecture

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sun, 17 Sep 2023 14:16:57 +0200
> 
> Eli Zaretskii wrote:
> 
> > If you know how to do one of them, you also know how to do
> > the other, because Emacs is a Lisp machine.
> 
> How do other applications, that are multi-threaded, solve the
> same obstacle, i.e. that of concurrent access to a big, shared
> global state?

Mult-threading and global state are two opposites: an application that
wants to be multi-threaded should have as small a global state as
possible, and where it cannot be avoided, use locking to access global
state from different threads.

> Because if the whole thing has to be locked for each thread to
> access, it can be disputed if that is indeed any parallelism
> at all. It will be multi-threaded and multi-core alright, but
> not parallel execution unless one counts waiting for a shared
> resource to become available as a sensible passivity.

That's what we have with Lisp threads now: while one thread runs, all
the others are stopped by a global lock.

> So one would have to have a more fine-grained access to the
> resource - by splitting it up in pieces. That way one thread
> could access r_i while another accesses r_j and so on.

This was discussed here earlier, and ion is that it's easier said than
done.

> Again it would be interesting to hear of how other
> applications are doing it.

There's a separate mutex for each global data structure.