在 2020年1月2日 +0800 AM12:21，Eli Zaretskii <eliz@gnu.org>，写道：
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.
Is it because there are many global resources in infrastructure of network and filesystem functions?
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.
Yes. Is there an efficient way for threads in module to communicate with emacs core? It is used for threads to send result data to emacs core. The only thing I known is sending signals to emacs which is not too efficient. I would like emacs core to create an event queue for modules and modules can send events to the queue.
Then it is possible to run guile in a module and write guile programs there.
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.
Yes. I don’t known how web browsers do this. Their web pages are rendered by different processes and then displayed in the same window.