bug#38807: [Feature request]: Support lisp workers like web workers.

[Eli Zaretskii]

> Date: Wed, 1 Jan 2020 10:59:31 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  Your idea in fact means to have several isolated Lisp machines in the
>  same process. But how can we do something like that without a very
>  radical redesign of Emacs, when so many things in Emacs are implicitly
>  part of the global state? Buffers, global variables, windows,
>  frames--all those are global resources, and every thread will want to
>  access them. Emacs was not designed to allow that.
> 
> All those global resources are not accessible by workers. Workers can only 
> access network, file system and
> other non-global resources. They only do the following things:
> 1. retrieve content from network, parse the data, and send the result(lisp 
> data) to the UI thread to present it
> 2. communicate with subprocesses, parse the data from subprocesses, and send 
> the result to the UI thread
> 3. do file indexing and send the index result to the UI thread
> 4. do other heavy work like mathematicl calculation and deep learning, send 
> the result to the UI thread

Then these threads cannot really run Lisp at all, nor even directly
affect Lisp data.  So in effect you want to be able to run threads
that don't enter the Lisp interpreter, nor modify any Lisp data.  We
already have that available: you can write a module which Emacs can
load, and that module can then start any number of threads doing any
calculations or network communications you want.  See emacs-module.h.

>  The disadvantage is that it is cumbersome to share data between the
>  two instances of Emacs, and large amounts of data will make that
>  inefficient. 
> 
> We may design an IPC for their communication.

For some data structures, yes.  But buffer text and long strings are
problematic, because the text can be very large.