Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Gregory Heytings <gregory@heytings.org> writes:

>> As I said, I hope that we can convert the important parts of the global 
>> state into thread-local state.
>>
>
> That's not possible alas.  Basically Emacs' global state is the memory it 
> has allocated, which is an enormous graph in which objects are the nodes 
> and pointers are the edges.  Any object may be linked to any number of 
> other objects (which means that you cannot isolate a subgraph, or even a 
> single object, of the graph), and any non-trivial Elisp function (as well 
> as garbage collection and redisplay) can change any of the objects and the 
> structure of the graph at any time (which means that two threads cannot 
> use the same graph concurrently without both of them taking the risk of 
> finding the graph suddenly different from what it was during the execution 
> of the previous opcode).

That's already similar for cooperative threads. The difference is that
sudden changes are limited to `thread-yield', while async threads will
have to be written keeping in mind that global variables may be changed
during execution unless explicitly locked.

And yes, we will need to implement locking on Elisp object level and
also on Elisp variable level.

But the very need to access global Elisp variables/objects from async
threads should not be considered a good practice (except near start/end
of thread execution). Most of processing should be done using threads'
local lexical scope.

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