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

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Does it mean that each threads contains a copy of the whole `globals'? I
> think I proposed this in the linked thread and it was objected as
> something taking a lot of memory.

It incorporates one pointer for each field within globals itself.  AFAIU
that was the initial impetus for introducing struct emacs_globals in the
first place.

> IMHO, copy-of-write would be better here - only store the thread-local
> values that are actually altered by the thread.

Of course only specbound values will be saved within each thread's
state, but each thread must maintain a pointer to the field that is
actually holding the value of the forwarded variables.

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

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

The problem lies in how to perform this efficiently.