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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: incal@dataswamp.org,  emacs-devel@gnu.org
> Date: Wed, 20 Sep 2023 09:05:39 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That avoids garbled values where part of a value is from one thread,
> > the other part from another thread.  But it does nothing to protect
> > the threads other than the one which changed the value from the
> > "surprise" of having stuff change under its feet.  Which is the main
> > problem to solve, since Emacs code is written under the assumption
> > that a variable in the global state doesn't change while some code
> > runs that doesn't change that variable.  That is why access to at
> > least some things will have to be serialized -- to allow threads that
> > access some part of the global state some level of control on what can
> > and cannot change while they are doing their job.
> 
> My solution (which I've put into practice in redisplay) is to save those
> values before sensitive code is executed, and to refer to those saved
> values within said code.

That is _everyone's_ solution, not just yours.  But it is not as easy
in practice as it may sound.  E.g., imagine a subroutine that is
called by some higher-level functions, where both the callers and the
subroutine need to access the same variable.  When other threads are
running, there's no longer a guarantee that both the caller and the
callee will see the same value of that variable.  If they must use the
same value, you now need to pass that variable to the callee via its
API, and this is not scalable when you have more than a couple,
especially if the callee is not called directly, but via several
intermediate callers.