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

[Dmitry Gutov <dmitry@gutov.dev>]

On 21/09/2023 14:49, Po Lu wrote:
> Ihor Radchenko<yantar92@posteo.net>  writes:
> 
>> As I understand his previous explanations, global variable values are
>> stored per-thread, if they were changed by that thread at some point.
>> For C-defined globals, the Vname instances are re-defined to
>> point to thread-local "globals" struct.
>>
>> I do not recall Po Lu providing the details on how the thread-local
>> variables are stored.
> Non-forwarded thread-local bindings are saved within a separate
> association list in Lisp_Symbol, where each element ties a thread to its
> local binding.  do_specbind and do_one_specbind manage this association
> list by introducing new associations.  set_internal and
> find_symbol_value search within this association list for a pair
> matching the current thread, and set or return its cdr respectively if
> it is present.
> 
> Within lispfwds, the pointer to the field itself is replaced with an
> offset to a field within struct thread_state which is set to a pointer
> to the matching field in `globals' or one of its local bindings.
> 
> Whenever a forwarded variable is specbound for the first time in a given
> thread, the designated field within that thread's state is set to a
> pointer into thread local storage, and once unbound, restored to its
> initial value within globals.

That reminds me of Clojure's threads and dynamic vars' semantics: 
https://clojure.org/about/concurrent_programming

   By default Vars are static, but per-thread bindings for Vars defined 
with metadata mark them as dynamic. Dynamic vars are also mutable 
references to objects. They have a (thread-shared) root binding which 
can be established by def, and can be set using *set!*, but only if they 
have been bound to a new storage location thread-locally using binding. 
Those bindings and any subsequent modifications to those bindings will 
only be seen within the thread by code in the dynamic scope of the 
binding block. Nested bindings obey a stack protocol and unwind as 
control exits the binding block.