emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 22 Sep 2023 02:43:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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.



reply via email to

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