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