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

[Dmitry Gutov]

On 23/09/2023 16:01, Eli Zaretskii wrote:
> > Date: Sat, 23 Sep 2023 15:53:11 +0300
> > Cc:acm@muc.de,incal@dataswamp.org,emacs-devel@gnu.org
> > From: Dmitry Gutov<dmitry@gutov.dev>
> >
> > On 23/09/2023 14:23, Eli Zaretskii wrote:
> > > As a trivial example, any function that modifies a file-visiting
> > > buffer could prompt the user if the file was meanwhile modified on
> > > disk.  This prompt is completely out of control of any Lisp program
> > > which does something that modifies buffer text.  How do we handle
> > > these cases? their name is a legion.
> > Any function that prompts the user is not supposed to be fast. So it
> > might as well acquire any number of global locks to do that.
> That's not my point.  My point is that if we say that changes to adapt
> existing code to threads are acceptable, we will have to make those
> changes all over our infrastructure, otherwise programs written for
> threads will not ready for threads 100%.

I agree: functions like yes-or-no-p will have to, internally in their 
implementation, acquire the "redisplay lock" or whatever it'll be 
called, and do other things to ensure that they work from non-default 
threads too.

This will likely make them a little slower compared to the single-thread 
model, but hopefully not to a degree that's humanly noticeable.