[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Sat, 23 Sep 2023 16:08:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 23/09/2023 16:01, Eli Zaretskii wrote:
Date: Sat, 23 Sep 2023 15:53:11 +0300
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]