Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii]

> Date: Sun, 17 Sep 2023 15:36:11 +0000
> Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> How about copy-on-write at a symbol
> value-cell/function-cell/property-list level?
> 
> A value in a value-cell (etc.) would have an associated thread value, the
> thread which "owns" it.  When thread1 gets cloned from thread0, it
> continues to use thread0's data state until it writes foo (e.g. by
> binding it).  This would create a new value/thread pair, foo/thread1.
> Further writes of foo by thread1 would continue to access foo/thread1.
> 
> Possibly, we could use just one owning thread for all the cells of a
> symbol.
> 
> When a thread terminates, all its owned variables would become garbage,
> to be collected by our new garbage collector.  ;-)

You assume that whatever the thread does can be discarded as garbage?
That's definitely not true in general: most things we do in Emacs
should leave some trace behind.  It is not clear when and how this
would happen under your proposal.  E.g., imagine that a thread runs
Gnus fetching articles, and try to describe how this will work.

> Clearly, there would have to be some variables which would be
> thread-global, i.e. there would be a single value cell shared by all
> threads.  There would also doubltless be other complications.

"Some variables"?  Our problem is that their name is a legion.  E.g.,
what do you propose to do with variables and changes to buffer text
that affect the display?  Or are you suggesting to have a separate
redisplay for each thread?  Or maybe you propose that each window has
its own thread, complete with its own display (and a separate thread
for each frame)?

These aspects need to be figured out if we want to discuss something
like this seriously.

> The advantage of this approach, if it could be made to work, is that it
> doesn't try to fight the massive global state which is Emacs Lisp,
> instead accepting it and embracing it.

I don't think you can avoid "fighting" it.  It's the elephant in the
room, and there's no way around that, because that global is the
backbone of the Emacs design, and all the Lisp programs and other
features implicitly assume it.