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

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Indeed, a simple #define will not be enough then, but we would not waste
>> memory copying the values that will never be changed anyway.
>
> On my machine, struct emacs_globals is 7490 bytes, just short of 7 KiB.
> struct thread_state amounts to 12704 bytes, which does not come across
> as excessive in this day and age.  Thread-local storage is then
> dynamically allocated as bindings materialize.

Sounds reasonable then. 7k does not look like a big deal to me.

>> We discussed asynchronous access to buffers earlier and concluded that
>> modifying a buffer (and its buffer-local values) asynchronously is a
>> hard problem. In particular, handling gap asynchronously is simply not
>> possible. It might be more practical to allow simultaneous read-only
>> access to the same buffer, but interlock writes to buffer object
>> (including moving gap, changing buffer text, and changing buffer-local
>> values).
>
> The gap and point are not buffer local values.  I'm referring to
> variables saved within local_var_alist, which must be modified to
> incorporate bindings for each thread.

As an aside: point should also be thread-local to make common Elisp code
work (like re-search-forward, for example).

> The problem lies in how to perform this efficiently.

The whole process of working with Lisp_Buffer_Local_Value is a bit
arcane with all its juggling of the values (`do_symval_forwarding',
`swap_in_symval_forwarding', etc) every time current_buffer changes.

I am wondering if you solved (seemingly) simpler cases with setting
Lisp_Fwd_Obj, Lisp_Fwd_Int, and Lisp_Fwd_Bool.

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