In principle I agree whole heartedly. When introducing parallelism and or concurrency into an old language, the "web workers" aproach, or Erlangs actors, to nam

In principle I agree whole heartedly. When introducing parallelism and or concurrency into an old language, the "web workers" aproach, or Erlangs actors, to name a decades older reference to a similar idea, should always be considered. The problem with emacs in particular is the use of the buffer as the most versatile data structure. Lot's of data that could live in some data structure lives in some overlay over some part of the buffer. And emacs is built on dynamic variables. Others in this thread have argued to "just refactor" them to lexically scoped variables. But that would decimate the largest vector to adapt and modify the system. Parallelizing Emacs needs to be a long-term endaveour, as the maintainers of Emacs already said years ago. I think Emacs could learn something from Clojure's story for parallelism. Make data structures immutable by default, and reference them from as few global variables as possible. The "make data structures immutable by default" ship has already sailed, but introducing additional immutable list/vector/map/set data structures with first class syntax support would allow newly written code to prepare for a more parallel future. Such immutable data structures could then be shared between different "ELisp web workers". The "as few global variables story" ship has already sailed, but again ELisp authors would start to consider reducing the number of global variables if it would enable multi-threading.