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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Sep 18, 2023 at 13:30:15 +0300, Eli Zaretskii wrote:
> > 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.

You mean that at the end of a thread, it will need to write results back
to variables "owned" by the calling thread.  Yes.  Either these variables
get marked as thread-global (not very attractive), or else we would need
to mark specific variables as not to be copied on write.

With a thread fetching Gnus articles, there is the additional
complication of having several such threads fetching from several servers
at once.  Then access to the result variables would need to be locked, to
prevent two threads overwriting eachother's results.  But this is so in
any multithreading system, no matter how it's done.

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

I envisage each buffer being "owned" by a thread, possibly a special
thread just controlling access to the buffer.  Variables like
scroll-margin would be the thread's own binding of it.  There are a large
number of dynamic variables in redisplay which, in the current Emacs,
when bound by a thread would affect Emacs globally.  This c-o-w proposal
would fix this problem.

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

I don't think several redisplay threads would be a good idea - usually,
there is just one screen Emacs is drawing on.  If we get down into
details, it might be worth having separate threads for each frame, or
even each window.

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

I'd like to emphasise that this copy-on-write idea is still just a vague
idea which might help, not a worked out firm proposal.

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

The c-o-w idea could steer around at least part of the globality.  I
think it would be relatively simple to implement (hah!) and wouldn't have
a large run-time cost, though of course there would be some.

-- 
Alan Mackenzie (Nuremberg, Germany).