Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

> The same update is happening when Emacs enters/exits let-binding or
> switches between current cooperative threads.

Which is actually quite a big issue.

When Emacs descents into let binding and dynamic scope is active, it
stores the existing variable value into a stack and sets the new value
globally, into symbol's value slot.

When ascending out of let, the existing value is discarded and the old
value is set globally, recovered from the stack.

And the cooperative threads simply manipulate the stack to store the
thread-local values before thread yields and load the values from the
next active stack. (though I did not look too close here)

--

The conclusion so far: it will be difficult to support dynamic scope
if we want things to run in parallel.

We would need to implement some way to store symbol values in every
thread (not necessarily all values, but at least the symbols changed by
thread function).

I can see several ways to approach this:

1. We can maintain a separate, sparse (just for changed variables)
   obarray inside threads, so that `intern'
   will point to thread-local symbol objects.

2. Force lexical scope inside threads, so that the values do not have to
   be stored in object value slots, but within per-thread lexical scope
   structure.
   This however, will not work when using things like `cl-letf' where
   Elisp code may want to temporarily set symbol function slots.

3. Store multiple value and function slots in symbol objects.

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