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

[Eli Zaretskii]

> Date: Sat, 23 Sep 2023 16:08:23 +0300
> Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

I'm not bothered by slowness, I'm much more bothered by the magnitude
of the changes this will incur.  I don't even know how to identify all
the places which would need such changes.