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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> So one thread uses setq, releases the lock, then another thread comes,
> takes the lock and changes the value of that variable, and when the
> first thread uses the variable after that, it will have a value
> different from the one the thread used in its setq?  How can one write
> a program under these conditions and know what it will do?

IMHO, there should be a new API to lock global variables by async
threads and/or set them.

I can imagine 3 possible scenarios:

1. Thread does not rely upon global variable value being constant, only
   upon being able to set it.

2. Thread sets global variable value and uses it later, expecting the
   value to remain constant.

3. Thread let-binds global variable.

(1) is easy - we just allow setting global value as we did in the past.
(2) is trickier. We might need to provide a new API, so that thread can
    put a lock onto the variables it works with.
    Or, alternatively, we might keep the global values thread-local
    until the thread terminates - it will most closely resemble what the
    existing Elisp code expects. Then, an API for explicitly setting
    top-level values will be needed for new code that will be written
    with concurrency in mind.
(3) is what Po Lu implemented in his current experimental code (AFAIU) -
    only set thread-local value with global variable is let-bound inside
    the thread. We know for sure that this value is neither reused by
    the concurrent threads nor needs to be kept outside the let-binding.

    BTW, Po Lu, what will happen when a thread spawns another async
    thread while some global variable is let-bound. Should the spawned
    thread somehow inherit the parent thread state?

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