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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 22 Sep 2023 18:00:42 +0200
> 
> Eli Zaretskii wrote:
> 
> >> There is no way around it, in order to prevent a race
> >> condition any global variable must be locked before it's
> >> value can be altered.
> >> 
> >> So `setq', `setf' and any other setter of global variables
> >> must first be refered to the locking mechanism where they
> >> either acquire the lock, perform the write, and release the
> >> lock; or, if the variable is already locked by some other
> >> thread wanting to do the same thing, they must be queued so
> >> they will get it in due time.
> >
> > So one thread uses setq, releases the lock, then another
> > thread comes, takes the lock and changes the value of that
> > variable, and when the first thread uses the variable after
> > that, it will have a value different from the one the thread
> > used in its setq? How can one write a program under these
> > conditions and know what it will do?
> 
> By relying not on global variables but on local variables.

It is impossible in Emacs to write a useful Lisp program that doesn't
rely on global variables and other parts of the global state.  You can
only write toy programs without that.