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

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Emanuel Berg <incal@dataswamp.org> writes:
>
>> Ihor Radchenko wrote:
>>
>>> Because implementation details are tricky - a lot of Elisp
>>> internal machinery is relying upon modifying global symbol
>>> objects [...]
>>
>> Yeah, but that should be fine, as long as they are locked and
>> unlocked safely, right?
>
> No.
>
> If we have something like (let ((case-fold-search t)) ...), we will lock
> `case-fold-search' symbol for the whole duration of `let' call and block
> any other threads trying to alter `case-fold-search' locally.

Emacs does not store the default value of each symbol in the variables
which they forward to.  All DEFVARs are thread local in this sense, for
each thread must be capable of simultaneously binding different values
to the same variable.

In my implementation, struct thread_state incorporates pointers to all
forwarded variables, each of which either points within thread_state
itself when its symbol is bound locally, or to `globals' otherwise.

Vcharset_map_path thus becomes:

#define Vcharset_map_path (*current_thread->f_Vcharset_map_path)

That being said, case-fold-search is a bad example.  I have not yet
established how buffer local variables will be efficiently represented
when multiple threads selecting the same buffer bind the same variables
simultaneously.  Once that hurdle is surmounted and the regex engine
itself is rendered thread-safe, threads will be capable of calling
regexp matching functions concurrently, with only their local bindings
of case_fold_search taking effect.  No symbol-based locking necessary.