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

[Dmitry Gutov <dmitry@gutov.dev>]

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
>>>> 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.

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.