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

[Eli Zaretskii <eliz@gnu.org>]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 19 Sep 2023 00:48:15 +0200
> 
> Eli Zaretskii wrote:
> 
> > it just means any such changes need to be communicated to
> > other "redisplaying" threads, so that they also restart
> 
> Instead of focusing on specific cases that one can imagine to
> be problematic, why not look for a general policy what
> should happen in the first place?

The general policy is a solved problem, so there's no reason to
consider it.

> So, what does it mean for a thread to lock a global variable?
> and set it? and use it? and then unlock it?
> 
> What does it mean to that thread for the duration of its
> execution? And what does it mean to another thread that is, or
> isn't, doing or wanting to do the same thing,
> possibly simultaneously?
> 
> After that, one can think of how to setup a mechanism that
> will safely uphold the model.
> 
> So first thing, define what a thread T can do to a global
> variable V.
> 
> Second thing, what do we want to happen, when another
> thread K does the same things in parallel, also to V?

We don't need to discuss all this because solutions for thread
synchronization exist for a long time.  We even use quite a few of
them already: the Lisp threads we have in Emacs now provide some of
these synchronization primitives, which are built on top of existing
capabilities built into the OS and existing thread libraries.

So the problem is not how to lock and serialize access to a variable
in general, the problem is how to do this in Emacs so that we won't
need to lock everything.