GNU bug report logs - #38807
[Feature request]: Support lisp workers like web workers.

Previous Next

Full log

Message #83 received at 38807 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38807 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#38807: [Feature request]: Support lisp workers like web
 workers.
Date: Fri, 3 Jan 2020 11:18:42 +0800

[Message part 1 (text/plain, inline)]

在 2020年1月2日 +0800 AM12:21，Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.