[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: Sun, 24 Sep 2023 03:29:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 23/09/2023 16:15, Eli Zaretskii wrote:
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
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.

That would be up to the implementor: do a patch, run with existing code, notice problems, patch some more. Etc. The issue is creating a reasonably complete (and useable) implementation that at least some developers start testing the waters.

Anyway, some concern about performance might be warranted. For example, the recent "Python without GIL" project describes a 9% difference in single-thread performance, which the author of course tried to make up for with new optimizations (https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit?pli=1).

I recall that even a 2% (?) difference caused by the symbols-with-positions feature was considered a problem not too long ago.

reply via email to

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