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.