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

[HaiJun Zhang <netjune@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

在 2020年1月1日 +0800 AM12:36，Eli Zaretskii <eliz@gnu.org>，写道：
> The Lisp interpreter already sort-of "queues" display changes, because
> it only changes Lisp data structures, and then the display engine
> references those data structures at display time. So those data
> structures serve as a kind-of "queue", since redisplay runs when Emacs
> is idle (i.e., the last Lisp command completed its job).
>
> But the problem is in the other direction: it's not that Lisp somehow
> "drives" the UI, it's that the UI frequently calls into Lisp as part
> of its job. The simplest example is mode-line format: it includes
> references to variables, and can also include :eval forms that call
> the interpreter.
>

It is much clearer to me now. We can keep them all as the UI thread.

> 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

Let the UI thread do as less work as possible.


> Your idea can be implemented with two processes, though. And there is
> already a package called emacs-async which does that:
>
> https://github.com/jwiegley/emacs-async
>

I knew this package. It is a good idea. Modern web browsers also use separate processes to render page content(one or more pages per process). They design specific IPC to let the worker processes to communicate with the main(UI) process. They have good performance and good user responsiveness.

I think emacs is much like web browsers. Both render large text content and care user responsiveness. We can learn from them.

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


[-- Attachment #2: Type: text/html, Size: 4015 bytes --]