[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread

From: Gregory Heytings
Subject: Re: Concurrency via isolated process/thread
Date: Sun, 09 Jul 2023 17:13:41 +0000

I don't believe any useful Lisp program in Emacs can be side-effect-free, for the purposes of this discussion. Every single one of them accesses the global state and changes the global state.

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

Given that, the only thing can be done in practice (which is what emacs-async does) is to create another Emacs instance, with another global state, in which some processing is done, and report the result back to the main Emacs instance.

The only alternative is to create another Emacs from scratch, with concurrency as one of its design principles.

Yes. I mean... look at Haskell. There is no shortage of pure functional libraries there.

I cannot follow you there: I don't know Haskell.

In short, pure functions in Haskell can utilize multiple CPUs automatically, without programmers explicitly writing code for multi-threading support.

The problem is that Elisp is not Haskell, and cannot be converted into something that resembles Haskell. Haskell functions are pure by default (impurity is the rare exception), Elisp functions are impure by default (purity is the rare exception).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]