[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs design and architecture. How about copy-on-write?
From: |
Emanuel Berg |
Subject: |
Re: Emacs design and architecture. How about copy-on-write? |
Date: |
Fri, 22 Sep 2023 17:59:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Ihor Radchenko wrote:
>>> Because implementation details are tricky - a lot of Elisp
>>> internal machinery is relying upon modifying global symbol
>>> objects [...]
>>
>> Yeah, but that should be fine, as long as they are locked
>> and unlocked safely, right?
>
> No.
>
> If we have something like (let ((case-fold-search t)) ...),
> we will lock `case-fold-search' symbol for the whole
> duration of `let' call and block any other threads trying to
> alter `case-fold-search' locally.
Yes, but so be it if that's the best we can do with `let' and
a multi-threaded, multi-core Emacs.
But one can also think of other ways to do that, for example
local copies for the duration of the form.
Overall, we will have to have a general solution, then examine
Lisp forms that do global variable setting on a form-by-form
basis and decide how they will relate to the general solution
in the best way possible, while still playing by its rules.
>> But, if one aspire to reduce the number of global variables
>> used, a great way of doing that is lexical `let'-closures,
>> here is an example that allows for the same default value
>> when the function is called from Lisp and when used as an
>> interactive command, yet the data is only hardcoded once
>> for each variable.
>
> Not every variable can be used within lexical scope.
> In particular special variables (see 12.10.4 Using Lexical
> Binding and `special-variable-p') are always treated outside
> lexical binding.
We are never gonna come up with a bottom-level solution that
works optimally for everything. Global/dynamic/special
variables are the exception and not the norm - yes, as we hear
from the name "special" BTW :) - and yes, they will have to be
locked one by one and for as long as it takes for the
execution to proceed safely.
--
underground experts united
https://dataswamp.org/~incal
- Re: Emacs design and architecture. How about copy-on-write?, (continued)
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/21
- Re: Emacs design and architecture. How about copy-on-write?,
Emanuel Berg <=
- RE: [External] : Re: Emacs design and architecture. How about copy-on-write?, Drew Adams, 2023/09/22
- Re: [External] : Re: Emacs design and architecture. How about copy-on-write?, Emanuel Berg, 2023/09/26
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/19
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/19
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/19
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/19
- Re: Emacs design and architecture. How about copy-on-write?, Eli Zaretskii, 2023/09/20
- Re: Emacs design and architecture. How about copy-on-write?, Ihor Radchenko, 2023/09/20
- Re: Emacs design and architecture. How about copy-on-write?, Po Lu, 2023/09/20
- Re: Emacs design and architecture. How about copy-on-write?, Emanuel Berg, 2023/09/19