[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: Ihor Radchenko
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Thu, 21 Sep 2023 08:35:06 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> The variable defined in C must be accessible by a C lvalue.  Namely,
>>   (*current_thread->f_Vname_of_the_variable)
> How is this different from
>   (setq name-of-variable SOMETHING)
> done by some thread to a global variable?

For global variables defined in C sources, Emacs maintains an actual C
variable that can be used directly to set and store the value. Then,

(setq name-of-global-variable-defined-in-C SOMETHING) must arrange to
set Vname_of_global_variable_defined_in_C C variable as well.

This is not needed for global variables defined in Elisp.

Under the hood, Vname binding is stored via Lisp_Objfwd. See #define
DEFVAR_LISP in lisp.h. This forwarding must be accounted for in threads,
if we want to make them asynchronous. Po Lu solved this by adding
thread-local "globals" structs.

In contrast, global Elisp variables defined in Elisp for not store
Lisp_Objfwd and instead contain their symbol value directly in their
Elisp symbol objects. Setting and reading these symbol values involves
the common API: Fsymbol_value and Fset, which are much easier to change
to work with async threads compared to the having to handle all the

 Vname = val;

that are expected to work in C level.

To sum up: Elisp-only globals are handled differently from globals
defined in C code and should thus be approached differently when
implementing async threads.

Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

reply via email to

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