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

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

[HaiJun Zhang]

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

I think the web worker is a good design for GUI applications such as web browser. The workers do heavy work and provide the results to the UI thread. The UI thread only displays the result and responds to user input events which makes good user responsiveness.

The web workers run in other context. They can’t access data in the UI thread. They can only communicate with the UI thread by calling some limited APIs.

See: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers


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

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

[Eli Zaretskii]

> Date: Mon, 30 Dec 2019 13:27:44 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> 
> I think the web worker is a good design for GUI applications such as web browser. The workers do heavy
> work and provide the results to the UI thread. The UI thread only displays the result and responds to user
> input events which makes good user responsiveness. 
> 
> The web workers run in other context. They can’t access data in the UI thread. They can only communicate
> with the UI thread by calling some limited APIs.

We have threads in Emacs, so you could start by using them, no?

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

[Dmitry Gutov]

On 30.12.2019 17:23, Eli Zaretskii wrote:
> We have threads in Emacs, so you could start by using them, no?

The main point of Web Workers is that they run in parallel to the main 
thread.

So the bit about not being able to access "data in the UI thread" is 
about no need for synchronization, I suppose.

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

[Eli Zaretskii]

> Cc: 38807@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Dec 2019 18:40:49 +0300
> 
> On 30.12.2019 17:23, Eli Zaretskii wrote:
> > We have threads in Emacs, so you could start by using them, no?
> 
> The main point of Web Workers is that they run in parallel to the main 
> thread.

This reminds me of an old joke: when a shop owner was approached by an
employee asking to work 5 days a week, the owner answered: let's start
with one, and then gradually arrive at 5.

More to the point, I did say "you could start", didn't I?

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 30 Dec 2019 13:27:44 +0800
>> From: HaiJun Zhang <netjune@outlook.com>
>> 
>> I think the web worker is a good design for GUI applications such as
>> web browser. The workers do heavy
>> work and provide the results to the UI thread. The UI thread only
>> displays the result and responds to user
>> input events which makes good user responsiveness. 
>> 
>> The web workers run in other context. They can’t access data in the
>> UI thread. They can only communicate
>> with the UI thread by calling some limited APIs.
>
> We have threads in Emacs, so you could start by using them, no?

The point seems to be that there is a dedicated UI thread. That we don't
have (yet) in Emacs, and I like this idea.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: HaiJun Zhang <netjune@outlook.com>,  38807@debbugs.gnu.org
> Date: Mon, 30 Dec 2019 19:31:26 +0100
> 
> The point seems to be that there is a dedicated UI thread. That we don't
> have (yet) in Emacs, and I like this idea.

We do have that on MS-Windows.  Except that you'll be surprised how
much of "UI" in Emacs cannot be done in a separate thread, mainly
because the Lisp machine is under such complete control of what the UI
does, and you cannot run several instances of the Lisp machine
simultaneously and asynchronously.

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

[Eli Zaretskii]

> Date: Mon, 30 Dec 2019 21:19:50 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: netjune@outlook.com, 38807@debbugs.gnu.org
> 
> because the Lisp machine is under such complete control of what the UI
> does

This might confuse.  What I meant is that the Lisp machine controls a
lot of what the UI does, not the other way around (of course).

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

[HaiJun Zhang]

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

在 2019年12月31日 +0800 AM3:19，Eli Zaretskii <eliz@gnu.org>，写道：
> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: HaiJun Zhang <netjune@outlook.com>, 38807@debbugs.gnu.org
> > Date: Mon, 30 Dec 2019 19:31:26 +0100
> >
> > The point seems to be that there is a dedicated UI thread. That we don't
> > have (yet) in Emacs, and I like this idea.
>
> We do have that on MS-Windows. Except that you'll be surprised how
> much of "UI" in Emacs cannot be done in a separate thread, mainly
> because the Lisp machine is under such complete control of what the UI
> does, and you cannot run several instances of the Lisp machine
> simultaneously and asynchronously.

What about the following idea:
1. Make the current lisp machine be customized which has two profiles:
    + full featured: as the current running lisp machine in emacs
    + subset one: without all UI functions
2. Run the full featured one as emacs does now. It acts as the master lisp machine(for UI only), which behave like the UI thread(process) in the web browser.
3. Run some subset ones for workers. Workers are started by the master lisp machine. Workers can send messages to the master machine by calling some APIs. The messages are copied to the master lisp machine, so GCs don’t need to work across machines.
4. Provide some APIs for them to communicate with each other.


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

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

[arthur miller]

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

Cool idea.

I have a question.  Is it even necessary for lisp machine to control UI?

Couldn't lisp machine post its "ui events" to a some kind of render queue and maybe input queue, instead of drawing and handling stuff immediately in an OS window? That could decouple drawing from the rest and could open for some other interesting stuff when it comes for rendering.

I don't know maybe another thread for input queue. Probably too much work and I really don't know if that would be possible with Emacs architecture, at least as of current.

I mean does lisp machine really need to know where it draws? It could as well just "draw" some events to a queue which could be rendered away in different passes, by different threads and so on.

Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: HaiJun Zhang <netjune@outlook.com>
Datum: 2019-12-31 01:42 (GMT+01:00)
Till: Michael Albinus <michael.albinus@gmx.de>, Eli Zaretskii <eliz@gnu.org>
Kopia: 38807@debbugs.gnu.org
Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.

在 2019年12月31日 +0800 AM3:19，Eli Zaretskii <eliz@gnu.org>，写道：
From: Michael Albinus <michael.albinus@gmx.de>
Cc: HaiJun Zhang <netjune@outlook.com>, 38807@debbugs.gnu.org
Date: Mon, 30 Dec 2019 19:31:26 +0100

The point seems to be that there is a dedicated UI thread. That we don't
have (yet) in Emacs, and I like this idea.

We do have that on MS-Windows. Except that you'll be surprised how
much of "UI" in Emacs cannot be done in a separate thread, mainly
because the Lisp machine is under such complete control of what the UI
does, and you cannot run several instances of the Lisp machine
simultaneously and asynchronously.

What about the following idea:
1. Make the current lisp machine be customized which has two profiles:
    + full featured: as the current running lisp machine in emacs
    + subset one: without all UI functions
2. Run the full featured one as emacs does now. It acts as the master lisp machine(for UI only), which behave like the UI thread(process) in the web browser.
3. Run some subset ones for workers. Workers are started by the master lisp machine. Workers can send messages to the master machine by calling some APIs. The messages are copied to the master lisp machine, so GCs don’t need to work across machines.
4. Provide some APIs for them to communicate with each other.


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

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

[Eli Zaretskii]

> Date: Tue, 31 Dec 2019 08:40:06 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: 38807@debbugs.gnu.org
> 
>  We do have that on MS-Windows. Except that you'll be surprised how
>  much of "UI" in Emacs cannot be done in a separate thread, mainly
>  because the Lisp machine is under such complete control of what the UI
>  does, and you cannot run several instances of the Lisp machine
>  simultaneously and asynchronously. 
> 
> What about the following idea:
> 1. Make the current lisp machine be customized which has two profiles:
>     + full featured: as the current running lisp machine in emacs
>     + subset one: without all UI functions
> 2. Run the full featured one as emacs does now. It acts as the master lisp machine(for UI only), which behave
> like the UI thread(process) in the web browser.
> 3. Run some subset ones for workers. Workers are started by the master lisp machine. Workers can send
> messages to the master machine by calling some APIs. The messages are copied to the master lisp
> machine, so GCs don’t need to work across machines.
> 4. Provide some APIs for them to communicate with each other.

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.

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.

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

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.

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

[HaiJun Zhang]

[-- 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 --]

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

[HaiJun Zhang]

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

在 2019年12月30日 +0800 PM11:40，Dmitry Gutov <dgutov@yandex.ru>，写道：
> On 30.12.2019 17:23, Eli Zaretskii wrote:
> > We have threads in Emacs, so you could start by using them, no?
>
> The main point of Web Workers is that they run in parallel to the main
> thread.
>
> So the bit about not being able to access "data in the UI thread" is
> about no need for synchronization, I suppose.

Yes. That is what I mean. They can do heavy work without pausing user input.


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

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

[HaiJun Zhang]

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

在 2019年12月31日 +0800 AM2:31，Michael Albinus <michael.albinus@gmx.de>，写道：
>
> The point seems to be that there is a dedicated UI thread. That we don't
> have (yet) in Emacs, and I like this idea.
>

We can even keep all in emacs currently as the “UI thread”and run another lisp machine for a worker.


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

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

[HaiJun Zhang]

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

在 2019年12月31日 +0800 AM12:26，Eli Zaretskii <eliz@gnu.org>，写道：
> This reminds me of an old joke: when a shop owner was approached by an
> employee asking to work 5 days a week, the owner answered: let's start
> with one, and then gradually arrive at 5.
>
> More to the point, I did say “you could start", didn't I?

I can’t understand this. Can you explain it?

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

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

[Eli Zaretskii]

> Date: Wed, 1 Jan 2020 11:20:25 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: 38807@debbugs.gnu.org
> 
> 在 2019年12月31日 +0800 AM12:26，Eli Zaretskii <eliz@gnu.org>，写道：
> 
>  This reminds me of an old joke: when a shop owner was approached by an
>  employee asking to work 5 days a week, the owner answered: let's start
>  with one, and then gradually arrive at 5.
> 
>  More to the point, I did say “you could start", didn't I? 
> 
> I can’t understand this. Can you explain it?

Whatever application you have in mind, try implementing it using what
we already have regarding Lisp threads, and see if the limitations
Michael mentioned are really so grave.  It could be that for some
applications what we have is good enough.  And if not, you will
collect some experience and understand better what additional features
do you need.

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

[HaiJun Zhang]

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

My understanding of the display flow:
1. an event comes which causes redisplay
2. the display engine prepares the glyph matrix
3. convert the glyph matrix to bitmap and display it

I think lots of work are in 2. During the work in 2, the display code needs to access many resources in lisp machine and even may eval lisp forms. The resources it accesses are too wildcard, so that we can't copy the resources to it and put them to queue. For multi-threading, we need a global lock.

在 2019年12月31日 +0800 AM9:39，arthur miller <arthur.miller@live.com>，写道：
> Cool idea.
>
> I have a question.  Is it even necessary for lisp machine to control UI?
>
> Couldn't lisp machine post its "ui events" to a some kind of render queue and maybe input queue, instead of drawing and handling stuff immediately in an OS window? That could decouple drawing from the rest and could open for some other interesting stuff when it comes for rendering.
>
> I don't know maybe another thread for input queue. Probably too much work and I really don't know if that would be possible with Emacs architecture, at least as of current.
>
> I mean does lisp machine really need to know where it draws? It could as well just "draw" some events to a queue which could be rendered away in different passes, by different threads and so on.
>
> Skickat från min Samsung Galaxy-smartphone.
>
>
>
> -------- Originalmeddelande --------
> Från: HaiJun Zhang <netjune@outlook.com>
> Datum: 2019-12-31 01:42 (GMT+01:00)
> Till: Michael Albinus <michael.albinus@gmx.de>, Eli Zaretskii <eliz@gnu.org>
> Kopia: 38807@debbugs.gnu.org
> Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.
>
> 在 2019年12月31日 +0800 AM3:19，Eli Zaretskii <eliz@gnu.org>，写道：
> > > From: Michael Albinus <michael.albinus@gmx.de>
> > > Cc: HaiJun Zhang <netjune@outlook.com>, 38807@debbugs.gnu.org
> > > Date: Mon, 30 Dec 2019 19:31:26 +0100
> > >
> > > The point seems to be that there is a dedicated UI thread. That we don't
> > > have (yet) in Emacs, and I like this idea.
> >
> > We do have that on MS-Windows. Except that you'll be surprised how
> > much of "UI" in Emacs cannot be done in a separate thread, mainly
> > because the Lisp machine is under such complete control of what the UI
> > does, and you cannot run several instances of the Lisp machine
> > simultaneously and asynchronously.
>
> What about the following idea:
> 1. Make the current lisp machine be customized which has two profiles:
>     + full featured: as the current running lisp machine in emacs
>     + subset one: without all UI functions
> 2. Run the full featured one as emacs does now. It acts as the master lisp machine(for UI only), which behave like the UI thread(process) in the web browser.
> 3. Run some subset ones for workers. Workers are started by the master lisp machine. Workers can send messages to the master machine by calling some APIs. The messages are copied to the master lisp machine, so GCs don’t need to work across machines.
> 4. Provide some APIs for them to communicate with each other.
>

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

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

[HaiJun Zhang]

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

OK. I got it.
One example is lsp-mode for dart language. One completion result is 10000 lines. And emacs doesn’t respond for about 3~4s. This experience kept me away from lsp-mode for half a year.
在 2020年1月1日 +0800 AM11:37，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Wed, 1 Jan 2020 11:20:25 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: 38807@debbugs.gnu.org
> >
> > 在 2019年12月31日 +0800 AM12:26，Eli Zaretskii <eliz@gnu.org>，写道：
> >
> > This reminds me of an old joke: when a shop owner was approached by an
> > employee asking to work 5 days a week, the owner answered: let's start
> > with one, and then gradually arrive at 5.
> >
> > More to the point, I did say “you could start", didn't I?
> >
> > I can’t understand this. Can you explain it?
>
> Whatever application you have in mind, try implementing it using what
> we already have regarding Lisp threads, and see if the limitations
> Michael mentioned are really so grave. It could be that for some
> applications what we have is good enough. And if not, you will
> collect some experience and understand better what additional features
> do you need.

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

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

[HaiJun Zhang]

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

While with the same dart project, the VSCode has good user responsiveness. As far as I known, the extensions of VSCode runs in separate process.
在 2020年1月1日 +0800 AM11:57，HaiJun Zhang <netjune@outlook.com>，写道：
> OK. I got it.
> One example is lsp-mode for dart language. One completion result is 10000 lines. And emacs doesn’t respond for about 3~4s. This experience kept me away from lsp-mode for half a year.
> 在 2020年1月1日 +0800 AM11:37，Eli Zaretskii <eliz@gnu.org>，写道：
> > > Date: Wed, 1 Jan 2020 11:20:25 +0800
> > > From: HaiJun Zhang <netjune@outlook.com>
> > > Cc: 38807@debbugs.gnu.org
> > >
> > > 在 2019年12月31日 +0800 AM12:26，Eli Zaretskii <eliz@gnu.org>，写道：
> > >
> > > This reminds me of an old joke: when a shop owner was approached by an
> > > employee asking to work 5 days a week, the owner answered: let's start
> > > with one, and then gradually arrive at 5.
> > >
> > > More to the point, I did say “you could start", didn't I?
> > >
> > > I can’t understand this. Can you explain it?
> >
> > Whatever application you have in mind, try implementing it using what
> > we already have regarding Lisp threads, and see if the limitations
> > Michael mentioned are really so grave. It could be that for some
> > applications what we have is good enough. And if not, you will
> > collect some experience and understand better what additional features
> > do you need.

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

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

[Michael Albinus]

HaiJun Zhang <netjune@outlook.com> writes:

>     The point seems to be that there is a dedicated UI thread. That we
>     don't
>     have (yet) in Emacs, and I like this idea.
>
> We can even keep all in emacs currently as the “UI thread”and run
> another lisp machine for a worker. 

I'm not expecting to get a UI thread with all glories it is specified
for web workers. I would already be happy if we could find a solution
for supporting user input in a threaded package, as it is discussed in
bug#25214 and bug#32426.

Best regards, Michael.

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

[arthur miller]

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



-------- Originalmeddelande --------
Från: HaiJun Zhang <netjune@outlook.com>
Datum: 2020-01-01 04:17 (GMT+01:00)
Till: Eli Zaretskii <eliz@gnu.org>, Michael Albinus <michael.albinus@gmx.de>
Kopia: 38807@debbugs.gnu.org
Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.

在 2019年12月31日 +0800 AM2:31，Michael Albinus <michael.albinus@gmx.de>，写道：

The point seems to be that there is a dedicated UI thread. That we don't
have (yet) in Emacs, and I like this idea.


> We can even keep all in emacs currently as
> the “UI thread”and run another lisp machine > for a worker.

Isn't emasc-server/emacsclient already already that?

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

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

[Eli Zaretskii]

> Date: Wed, 1 Jan 2020 12:02:35 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org
> 
> While with the same dart project, the VSCode has good user responsiveness. As far as I known, the
> extensions of VSCode runs in separate process.

Can you even remotely compare the degree of control the VSCode
extension language can have on the UI, with what Emacs gives you?

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.

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

[Eli Zaretskii]

> Date: Wed, 1 Jan 2020 11:47:49 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org>
> 
> My understanding of the display flow:
> 1. an event comes which causes redisplay

More often than not, it is not an event, but a command that changes
Lisp data (buffer text, overlays, text properties, position of point,
new or deleted windows, etc.).

> 2. the display engine prepares the glyph matrix
> 3. convert the glyph matrix to bitmap and display it
> 
> I think lots of work are in 2.

Actually, 3 is also a lot of work.

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

[HaiJun Zhang]

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

在 2020年1月1日 +0800 PM10:52，arthur miller <arthur.miller@live.com>，写道：
>
> > We can even keep all in emacs currently as
> > the “UI thread”and run another lisp machine > for a worker.
>
> Isn’t emasc-server/emacsclient already already that?

Yes and no. The emacsclient do too less work to be a worker. Ratio of their work is 10:1? I would it to be 1:10? Workers should do most heavy work.


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

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

[HaiJun Zhang]

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

在 2020年1月1日 +0800 PM11:32，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Wed, 1 Jan 2020 12:02:35 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org
> >
> > While with the same dart project, the VSCode has good user responsiveness. As far as I known, the
> > extensions of VSCode runs in separate process.
>
> Can you even remotely compare the degree of control the VSCode
> extension language can have on the UI, with what Emacs gives you?


I will try to do it when I have time.


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

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

[HaiJun Zhang]

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

在 2020年1月1日 +0800 PM5:14，Michael Albinus <michael.albinus@gmx.de>，写道：
> HaiJun Zhang <netjune@outlook.com> writes:
>
> > The point seems to be that there is a dedicated UI thread. That we
> > don't
> > have (yet) in Emacs, and I like this idea.
> >
> > We can even keep all in emacs currently as the “UI thread”and run
> > another lisp machine for a worker.
>
> I'm not expecting to get a UI thread with all glories it is specified
> for web workers. I would already be happy if we could find a solution
> for supporting user input in a threaded package, as it is discussed in
> bug#25214 and bug#32426.
>
> Best regards, Michael.

The threading support introduced in emacs 26 is cool. But it is too complex when every thread can control UI and interact with user. While the web worker model is much simpler.


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

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

[HaiJun Zhang]

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

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




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

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

[HaiJun Zhang]

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

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

For web worker, they have different contexts. The following is from MDN(https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers):

workers run in another global context that is different from the current window. Thus, using the windowshortcut to get the current global scope (instead of self) within a Worker will return an error.
The worker context is represented by a DedicatedWorkerGlobalScope object in the case of dedicated workers (standard workers that are utilized by a single script; shared workers use SharedWorkerGlobalScope). A dedicated worker is only accessible from the script that first spawned it, whereas shared workers can be accessed from multiple scripts.


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

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

[HaiJun Zhang]

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

在 2020年1月2日 +0800 AM12:23，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Wed, 1 Jan 2020 11:47:49 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org>
> >
> > My understanding of the display flow:
> > 1. an event comes which causes redisplay
>
> More often than not, it is not an event, but a command that changes
> Lisp data (buffer text, overlays, text properties, position of point,
> new or deleted windows, etc.).
>

Thanks for your explanation.

> > 2. the display engine prepares the glyph matrix
> > 3. convert the glyph matrix to bitmap and display it
> >
> > I think lots of work are in 2.
>
> Actually, 3 is also a lot of work.

Then 3 can be done in a separate thread from 2 and 1?


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

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

[Eli Zaretskii]

> Date: Fri, 3 Jan 2020 10:52:59 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 38807@debbugs.gnu.org
> 
> The threading support introduced in emacs 26 is cool. But it is too complex when every thread can control UI
> and interact with user. While the web worker model is much simpler.

How do you write a useful Lisp application for a thread if you have no
way of displaying any messages?  Besides, some low-level APIs you'd
use in any Lisp will display messages even if your code doesn't.

So some solution for user interaction from threads is still needed, or
else the thread system will not be useful for writing Lisp programs.

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

[Eli Zaretskii]

> Date: Fri, 3 Jan 2020 11:18:42 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.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? 

Yes.  Every variable you want to reference is either global or local
to some buffer, for example.  Just look at any Lisp application in
Emacs and try to analyze its dependence on the global state, and you
will immediately see the problem.

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

There are ways of communications (e.g., you can call any Emacs
function), but if more is needed, we can add that.  Some design is
necessary, though, to identify what else is needed and why.

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

Shared memory?

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

[Eli Zaretskii]

> Date: Fri, 3 Jan 2020 11:45:51 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, arthur.miller@live.com, 
>  38807@debbugs.gnu.org
> 
>  2. the display engine prepares the glyph matrix
>  3. convert the glyph matrix to bitmap and display it
> 
>  I think lots of work are in 2.
> 
>  Actually, 3 is also a lot of work. 
> 
> Then 3 can be done in a separate thread from 2 and 1?

How would that help?  Until 3 is done, the user doesn't see the
display updated.  And if you think 3 doesn't touch any Lisp, then
thats not true, just see how many times you find "Lisp_Object" in,
say, xterm.c.

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

[arthur miller]

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

I mean that emacsclient is sort of rendering thread while Emacs server is sort of hard working part.

I have honestly never looked at the code for server/client so I don't know how separation is done. I ment it more as a logical view of those.It would be interesting to learn more about it  though if some dev who is introduced in internals could a line or two and explain how responsibility is divided between the two.

Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: HaiJun Zhang <netjune@outlook.com>
Datum: 2020-01-03 02:49 (GMT+01:00)
Till: Eli Zaretskii <eliz@gnu.org>, Michael Albinus <michael.albinus@gmx.de>, arthur miller <arthur.miller@live.com>
Kopia: 38807@debbugs.gnu.org
Ämne: RE: bug#38807: [Feature request]: Support lisp workers like web workers.

在 2020年1月1日 +0800 PM10:52，arthur miller <arthur.miller@live.com>，写道：

> We can even keep all in emacs currently as
> the “UI thread”and run another lisp machine > for a worker.

Isn’t emasc-server/emacsclient already already that?

Yes and no. The emacsclient do too less work to be a worker. Ratio of their work is 10:1? I would it to be 1:10? Workers should do most heavy work.


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

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

[arthur miller]

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

This issue on their github might help you to start in right direction :-):


https://github.com/microsoft/vscode/issues/1833

I don't if things changed since 2017 though.

Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: HaiJun Zhang <netjune@outlook.com>
Datum: 2020-01-03 03:07 (GMT+01:00)
Till: Eli Zaretskii <eliz@gnu.org>
Kopia: 38807@debbugs.gnu.org, dgutov@yandex.ru
Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.

在 2020年1月1日 +0800 PM11:32，Eli Zaretskii <eliz@gnu.org>，写道：
Date: Wed, 1 Jan 2020 12:02:35 +0800
From: HaiJun Zhang <netjune@outlook.com>
Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org

While with the same dart project, the VSCode has good user responsiveness. As far as I known, the
extensions of VSCode runs in separate process.

Can you even remotely compare the degree of control the VSCode
extension language can have on the UI, with what Emacs gives you?


I will try to do it when I have time.


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

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

[arthur miller]

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

As a concept, I am not sure a thread is the best solution to implement for a high level scripting runtime as Emacs lisp. Thread is a relatively primitive concept and leaves a lot to  applications programmer to decide and manage. In concurrent programming a thread is OK-ish concept, but it might not be the best for truly parallel problem solving.

Creating more threads than there are physical cpus creates overhead that might eat up benefits of parallelism. It  also forces a programmer to think in terms of machine, scheduling, synchronization etc. It can be more effective and more lisp-ish to think in terms of tasks and let the core manage the threads and scheduling on it's own.

Tasks let us think about the work we wish to perform and not how to perform it. It lets runtime create number of worker threads and schedule them automatically instead of forcing programmers to join, synchronize etc

As a concept a web worker is just a worker thread introduced as idea in various single threaded gui toolkits long ago. Java's Swing popularized worker threads heavily back in days, and I don't remember if MFC also made a deal of those before Swing or after.

Anyway, these were just ordinary threads,  doing some work, like populating big lists and similar, nothing special. However back in days threads were cheap. Everything run on one CPU, and threaded programming was mostly what we today call concurrent programming.

Since Swing and Mfc were big things, we have got multi core CPUs as mainstream and threads have got much more expensive to create and communicate with. Java threads back at days where super cheap to create. I am not sure how expensive are posix threads on different cpus, but I know that win32 threads are quite expensive/slow. For a small work it might be more expensive to process it in separate thread.

Tasks can be mapped on entire thread or put into a queue for physical threads to pick them up. Thus I think tasks might be more suited for say an input queue or render queue and similar.

If I remember well, certain version of DirectX used to process input in separate thread, which they abandoned in some later version. However I stopped to work with dx years ago, before dx10 come out, so I don't know how they do nowadays.


Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: HaiJun Zhang <netjune@outlook.com>
Datum: 2020-01-03 04:36 (GMT+01:00)
Till: Eli Zaretskii <eliz@gnu.org>
Kopia: 38807@debbugs.gnu.org, michael.albinus@gmx.de
Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.

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

For web worker, they have different contexts. The following is from MDN(https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers):


workers run in another global context that is different from the current window</en-US/docs/Web/API/Window>. Thus, using the window</en-US/docs/Web/API/Window>shortcut to get the current global scope (instead of self</en-US/docs/Web/API/Window/self>) within a Worker</en-US/docs/Web/API/Worker> will return an error.

The worker context is represented by a DedicatedWorkerGlobalScope</en-US/docs/Web/API/DedicatedWorkerGlobalScope> object in the case of dedicated workers (standard workers that are utilized by a single script; shared workers use SharedWorkerGlobalScope</en-US/docs/Web/API/SharedWorkerGlobalScope>). A dedicated worker is only accessible from the script that first spawned it, whereas shared workers can be accessed from multiple scripts.


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

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

[arthur miller]

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





Skickat från min Samsung Galaxy-smartphone.



>
>  2. the display engine prepares the glyph matrix
>  3. convert the glyph matrix to bitmap and display it
>
>  I think lots of work are in 2.
>
>  Actually, 3 is also a lot of work.
>
> Then 3 can be done in a separate thread from 2 and 1?

> How would that help?  Until 3 is done, the user doesn't see the

Couldn't prepare and converting to bitmap, inclusive rendering the bitmap bo done in a separate thread from displaying the same?

Of course, displaying can not be done until previous work has finished, so I don't know if Emacs could interleave the work with something else useful?


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

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

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org>
> Date: Fri, 3 Jan 2020 13:35:49 +0000
> 
> I mean that emacsclient is sort of rendering thread while Emacs server is sort of hard working part.

No, it isn't.  emacsclient just sends a command to Emacs telling it to
visit a file and display it in a frame.  All the rendering is done by
the "server", i.e. Emacs itself.

> I have honestly never looked at the code for server/client so I don't know how separation is done.

It's easy to see that by reading server.el.

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

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "michael.albinus@gmx.de" <michael.albinus@gmx.de>, "38807@debbugs.gnu.org"
> 	<38807@debbugs.gnu.org>
> Date: Fri, 3 Jan 2020 14:19:40 +0000
> 
> > Then 3 can be done in a separate thread from 2 and 1?
> 
> > How would that help?  Until 3 is done, the user doesn't see the
> 
> Couldn't prepare and converting to bitmap, inclusive rendering the bitmap bo done in a separate thread from
> displaying the same?

We don't really generate a bitmap, it's an inaccurate description of
what the terminal-specific backend of the display engine does.

And if you change it to generate a bitmap, then doing so is most of
the work, and it needs to consult Lisp data, at least in its current
incarnation.  So proposing that this runs in a separate thread still
doesn't solve the problem of separating some significant workload from
Lisp, that is something that needs to be designed.

> Of course, displaying can not be done until previous work has finished, so I don't know if Emacs could
> interleave the work with something else useful?

In general, it is not useful to have a display system that doesn't
update the screen in near-real time.  If you ever tried editing via a
slow remote connection, you know what I mean.  So display must happen
very soon after the command which triggers it finishes, or users will
complain.

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

[arthur miller]

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

Aha. Ok, thx för the info. I didnt know lyckas implemented. Will take a look at server.el.



Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: Eli Zaretskii <eliz@gnu.org>
Datum: 2020-01-03 15:26 (GMT+01:00)
Till: arthur miller <arthur.miller@live.com>
Kopia: netjune@outlook.com, michael.albinus@gmx.de, 38807@debbugs.gnu.org
Ämne: Re: bug#38807: [Feature request]: Support lisp workers like web workers.

> From: arthur miller <arthur.miller@live.com>
> CC: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org>
> Date: Fri, 3 Jan 2020 13:35:49 +0000
>
> I mean that emacsclient is sort of rendering thread while Emacs server is sort of hard working part.

No, it isn't.  emacsclient just sends a command to Emacs telling it to
visit a file and display it in a frame.  All the rendering is done by
the "server", i.e. Emacs itself.

> I have honestly never looked at the code for server/client so I don't know how separation is done.

It's easy to see that by reading server.el.

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

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

[HaiJun Zhang]

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

在 2020年1月3日 +0800 PM1:59，Eli Zaretskii <eliz@gnu.org>，写道：
>
> How do you write a useful Lisp application for a thread if you have no
> way of displaying any messages?

Workers are background workers. They don’t display messages directly. They post the error messages to the UI part of the lisp application.

For a lisp application such as an email client, it is splitted to two parts: the UI part and the worker part. The UI part may has two callbacks(or event handlers):
1. on_new_email
2. on_error

If the worker fetches an email successfully, it sends an event to the UI part and the on_new_email callback of the UI part will be called. If the worker fails, it sends an error to the UI part and the on_error callback will be called. The on_error callback can display the error message to user.



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

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

[HaiJun Zhang]

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

在 2020年1月3日 +0800 PM2:02，Eli Zaretskii <eliz@gnu.org>，写道：
> There are ways of communications (e.g., you can call any Emacs
> function),

Can threads in modules call Emacs functions? If yes, it is powerful.



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

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

[HaiJun Zhang]

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

在 2020年1月3日 +0800 PM2:06，Eli Zaretskii <eliz@gnu.org>，写道：
> How would that help? Until 3 is done, the user doesn't see the
> display updated. And if you think 3 doesn't touch any Lisp, then
> thats not true, just see how many times you find "Lisp_Object" in,
> say, xterm.c.
>
OK. This branch of the discussion is for @arthur miller.

If 3 can’t be done in separate thread, then we can keep them all as the “UI thread". And let it do as less work as possible by splitting some of work to background workers. Then better user responsiveness is possible.



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

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

[HaiJun Zhang]

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

在 2020年1月3日 +0800 PM2:02，Eli Zaretskii <eliz@gnu.org>，写道：
>
> There are ways of communications (e.g., you can call any Emacs
> function), but if more is needed, we can add that. Some design is
> necessary, though, to identify what else is needed and why.
>

There is discussion related with this. https://emacs-china.org/t/lsp-mode/11238/36


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

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

[HaiJun Zhang]

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

在 2020年1月3日 +0800 PM9:38，arthur miller <arthur.miller@live.com>，写道：
> This issue on their github might help you to start in right direction :-):
>
>
> https://github.com/microsoft/vscode/issues/1833
>
> I don't if things changed since 2017 though.
>
> Skickat från min Samsung Galaxy-smartphone.
>

It is what I want to find. Thank you very much.


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

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

[HaiJun Zhang]

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

Workers don’t have to be in dedicated native threads. It is decided by the lisp machine if they are run in a lisp machine.

在 2020年1月3日 +0800 PM10:11，arthur miller <arthur.miller@live.com>，写道：
> As a concept, I am not sure a thread is the best solution to implement for a high level scripting runtime as Emacs lisp. Thread is a relatively primitive concept and leaves a lot to  applications programmer to decide and manage. In concurrent programming a thread is OK-ish concept, but it might not be the best for truly parallel problem solving.
>
> Creating more threads than there are physical cpus creates overhead that might eat up benefits of parallelism. It  also forces a programmer to think in terms of machine, scheduling, synchronization etc. It can be more effective and more lisp-ish to think in terms of tasks and let the core manage the threads and scheduling on it's own.
>
> Tasks let us think about the work we wish to perform and not how to perform it. It lets runtime create number of worker threads and schedule them automatically instead of forcing programmers to join, synchronize etc
>
> As a concept a web worker is just a worker thread introduced as idea in various single threaded gui toolkits long ago. Java's Swing popularized worker threads heavily back in days, and I don't remember if MFC also made a deal of those before Swing or after.
>
> Anyway, these were just ordinary threads,  doing some work, like populating big lists and similar, nothing special. However back in days threads were cheap. Everything run on one CPU, and threaded programming was mostly what we today call concurrent programming.
>
> Since Swing and Mfc were big things, we have got multi core CPUs as mainstream and threads have got much more expensive to create and communicate with. Java threads back at days where super cheap to create. I am not sure how expensive are posix threads on different cpus, but I know that win32 threads are quite expensive/slow. For a small work it might be more expensive to process it in separate thread.
>
> Tasks can be mapped on entire thread or put into a queue for physical threads to pick them up. Thus I think tasks might be more suited for say an input queue or render queue and similar.
>
> If I remember well, certain version of DirectX used to process input in separate thread, which they abandoned in some later version. However I stopped to work with dx years ago, before dx10 come out, so I don't know how they do nowadays.
>
>
> Skickat från min Samsung Galaxy-smartphone.
>
>
>
> -------- Originalmeddelande --------
> Från: HaiJun Zhang <netjune@outlook.com>
> Datum: 2020-01-03 04:36 (GMT+01:00)
> Till: Eli Zaretskii <eliz@gnu.org>
> Kopia: 38807@debbugs.gnu.org, michael.albinus@gmx.de
> Ämne: bug#38807: [Feature request]: Support lisp workers like web workers.
>
> 在 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.
>
> For web worker, they have different contexts. The following is from MDN(https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers):
>
> workers run in another global context that is different from the current window. Thus, using the windowshortcut to get the current global scope (instead of self) within a Worker will return an error.
> The worker context is represented by a DedicatedWorkerGlobalScope object in the case of dedicated workers (standard workers that are utilized by a single script; shared workers use SharedWorkerGlobalScope). A dedicated worker is only accessible from the script that first spawned it, whereas shared workers can be accessed from multiple scripts.
>

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

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

[HaiJun Zhang]

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

I extracted some text from the VSCode extension development guide. Hope you can get an overview first.


The extension host:
====================
Extension host is a Node.js process in VS Code responsible for loading and running extensions. Although you don't need to worry about the Extension Host when you are writing extensions, it is still useful to know what the Extension Host does to your extension.

URL: https://code.visualstudio.com/api/advanced-topics/extension-host


Extension Manifest:
====================
Every Visual Studio Code extension needs a manifest file package.json at the root of the extension directory structure.

URL: https://code.visualstudio.com/api/references/extension-manifest


Contribute Points:
===================
Contribution Points are a set of JSON declarations that you make in the contributes field of the package.json Extension Manifest. Your extension registers Contribution Points to extend various functionalities within Visual Studio Code. Here is a list of all available Contribution Points:

configuration
configurationDefaults
commands
menus
keybindings
languages
debuggers
breakpoints
grammars
themes
snippets
jsonValidation
views
viewsContainers
problemMatchers
problemPatterns
taskDefinitions
colors
typescriptServerPlugins
resourceLabelFormatters

URL: https://code.visualstudio.com/api/references/contribution-points


Extending Workbench:
====================
"Workbench" refers to the overall Visual Studio Code UI that encompasses the following UI components:

Title Bar
Activity Bar
Side Bar
Panel
Editor Group
Status Bar

VS Code provides various APIs that allow you to add your own components to the Workbench.

URL: https://code.visualstudio.com/api/extension-capabilities/extending-workbench

在 2020年1月1日 +0800 PM11:32，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Wed, 1 Jan 2020 12:02:35 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org
> >
> > While with the same dart project, the VSCode has good user responsiveness. As far as I known, the
> > extensions of VSCode runs in separate process.
>
> Can you even remotely compare the degree of control the VSCode
> extension language can have on the UI, with what Emacs gives you?

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

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

[Eli Zaretskii]

> Date: Sat, 4 Jan 2020 13:19:46 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  How do you write a useful Lisp application for a thread if you have no
>  way of displaying any messages?  
> 
> Workers are background workers. They don’t display messages directly. They post the error messages to the
> UI part of the lisp application.

How would that work?  We don't have any such message queues in Emacs,
and no machinery to display them, nor for telling the user which job
reported the message.

And again, some low-level Lisp functions issue messages when they like
that, out of the application's control.  What do you do with those?

> For a lisp application such as an email client, it is splitted to two parts: the UI part and the worker part. The UI
> part may has two callbacks(or event handlers):
> 1. on_new_email
> 2. on_error
> 
> If the worker fetches an email successfully, it sends an event to the UI part and the on_new_email callback of
> the UI part will be called. If the worker fails, it sends an error to the UI part and the on_error callback will be
> called. The on_error callback can display the error message to user.

I'm saying that fetching email doesn't need any Lisp, it can be done
in C.  And if so, you don't need Lisp-level threads at all.

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

[Eli Zaretskii]

> Date: Sat, 4 Jan 2020 13:26:24 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  There are ways of communications (e.g., you can call any Emacs
>  function),  
> 
> Can threads in modules call Emacs functions?

Yes.  It's in the docs, please read about modules in the ELisp manual.

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

[Eli Zaretskii]

> Date: Sat, 4 Jan 2020 16:11:23 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org
> 
> I extracted some text from the VSCode extension development guide. Hope you can get an overview first.

Where does it say how to cause VSCode display an equivalent to an
image or an overlay string over some text in a buffer?

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

[HaiJun Zhang]

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

The UI extension is in “Extending Workbench”.

Extension examples:
1. add icon buttons on the title menu bar(like toolbar)
2. add icon buttons on the status bar
3. add items to any existing menu or add new context menu
4. add an outline view to show symbol list(like imenu with a list view), and add a context menu for the symbols in the list
5. add an virtual filesystem view to show files from a ftp server and open files in it
6. call any command in the VSCode and get the result. The command may be a file chooser dialog.
7. call any command registered by other extensions and get the result
8. register commands for user to use. The command is implemented in the extension with typescript(like javescript). The command can be run by user with Ctrl-P(like M-x in emacs) or can be called by other extensions(like in 7).
9. create a webview and show it like an opened file. It can be used to preview markdown.
10. add key bindings
11. create an slot in log panel and output logs to it.
12. display notifications(like the tooltip window in emacs)
13. show progress
14. get opened file list or get the active file


在 2020年1月1日 +0800 PM11:32，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Wed, 1 Jan 2020 12:02:35 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: dgutov@yandex.ru, 38807@debbugs.gnu.org
> >
> > While with the same dart project, the VSCode has good user responsiveness. As far as I known, the
> > extensions of VSCode runs in separate process.
>
> Can you even remotely compare the degree of control the VSCode
> extension language can have on the UI, with what Emacs gives you?

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

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

[HaiJun Zhang]

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

在 2020年1月4日 +0800 PM4:59，Eli Zaretskii <eliz@gnu.org>，写道：
> How would that work? We don't have any such message queues in Emacs,
> and no machinery to display them, nor for telling the user which job
> reported the message.

Some APIs need to be added for communication use. The UI part of the email client known what happens and will tell the user.

> And again, some low-level Lisp functions issue messages when they like
> that, out of the application's control. What do you do with those?
>

The lisp machine need to be modified for running workers. When running workers, It may save the messages to a log file.

> I'm saying that fetching email doesn't need any Lisp, it can be done
> in C. And if so, you don’t need Lisp-level threads at all.

Many emacs hackers may prefer lisp to C. Writing lisp is faster than C. And compiling C is not an easy
 thing for many users.


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

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

[Eli Zaretskii]

> Date: Sat, 4 Jan 2020 17:33:18 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  How would that work? We don't have any such message queues in Emacs,
>  and no machinery to display them, nor for telling the user which job
>  reported the message.
> 
> Some APIs need to be added for communication use. The UI part of the email client known what happens and
> will tell the user. 

Sorry, such general and vague suggestions aren't useful.  You need to
propose specific changes that are consistent with how Emacs is
designed and implemented.  You need to describe those new APIs, and
you need to tell how will they be used by the existing code that
displays messages in the echo area.

It goes without saying that an editor different from Emacs could be
designed from scratch to support multi-threading between the UI and
the processing engine.  The issues at hand are (a) would such an
editor be as powerful and flexible as Emacs, in terms of letting the
programs written in the extension language control what is being
displayed and where; and (b) would it be possible to add such
threading to Emacs as it is now without completely redesigning how it
processes input events and how it displays messages to the user.

So any proposals in that direction must be more concrete and directly
related to how Emacs works now, otherwise this will not be a
discussion of any practical interest for Emacs development.

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

[HaiJun Zhang]

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

在 2020年1月4日 +0800 PM5:51，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Sat, 4 Jan 2020 17:33:18 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> >
> > How would that work? We don't have any such message queues in Emacs,
> > and no machinery to display them, nor for telling the user which job
> > reported the message.
> >
> > Some APIs need to be added for communication use. The UI part of the email client known what happens and
> > will tell the user.
>
> Sorry, such general and vague suggestions aren't useful. You need to
> propose specific changes that are consistent with how Emacs is
> designed and implemented. You need to describe those new APIs, and
> you need to tell how will they be used by the existing code that
> displays messages in the echo area.

On the UI part, create a worker like this:
——————xxxx——————
fetch_mail_worker = new Worker(xxx)

fetch_mail_worker.onmessage = function (msg) {
    // display the new mail
};

fetch_mail_worker.onerror = function (error) {
    message(“fetch mail error: %s”, error)
};

fetch_mail_worker.start()
——————xxxx———————

On the worker part, fetch emails and post messages or error:
——————xxxx———————-
while(true) {
    error = fetch_next_mail(&msg)
    if error != nil {
       post_error(error)
       break
    }

    post_message(msg)
}
——————xxxx———————-

> It goes without saying that an editor different from Emacs could be
> designed from scratch to support multi-threading between the UI and
> the processing engine. The issues at hand are (a) would such an
> editor be as powerful and flexible as Emacs, in terms of letting the
> programs written in the extension language control what is being
> displayed and where; and (b) would it be possible to add such
> threading to Emacs as it is now without completely redesigning how it
> processes input events and how it displays messages to the user.
>
> So any proposals in that direction must be more concrete and directly
> related to how Emacs works now, otherwise this will not be a
> discussion of any practical interest for Emacs development.

I don’t known if the above code is concrete.


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

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

[Eli Zaretskii]

> Date: Mon, 6 Jan 2020 13:08:28 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  Sorry, such general and vague suggestions aren't useful. You need to
>  propose specific changes that are consistent with how Emacs is
>  designed and implemented. You need to describe those new APIs, and
>  you need to tell how will they be used by the existing code that
>  displays messages in the echo area.
> 
> On the UI part, create a worker like this:
> ——————xxxx——————
> fetch_mail_worker = new Worker(xxx)
> 
> fetch_mail_worker.onmessage = function (msg) {
>     // display the new mail
> };
> 
> fetch_mail_worker.onerror = function (error) {
>     message(“fetch mail error: %s”, error)
> };
> 
> fetch_mail_worker.start()
> ——————xxxx———————
> 
> On the worker part, fetch emails and post messages or error:
> ——————xxxx———————-
> while(true) {
>     error = fetch_next_mail(&msg)
>     if error != nil {
>        post_error(error)
>        break
>     }
> 
>     post_message(msg)
> }
> ——————xxxx———————-

This is very abstract.  I hoped you could describe this in terms of
relevant Emacs APIs and features.

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

[HaiJun Zhang]

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

在 2020年1月4日 +0800 PM5:00，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Sat, 4 Jan 2020 13:26:24 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> >
> > There are ways of communications (e.g., you can call any Emacs
> > function),
> >
> > Can threads in modules call Emacs functions?
>
> Yes. It’s in the docs, please read about modules in the ELisp manual.

I known module code can call emacs functions. But is it true for threads in module?

See this: https://github.com/emacs-lsp/lsp-mode/issues/676#issuecomment-476700911

> That means if a native-code thread is to be run in parallel with the UI thread, it can never access an Env.


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

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

[Eli Zaretskii]

> Date: Sat, 21 Mar 2020 10:24:37 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
> I known module code can call emacs functions. But is it true for threads in module?

Since the Lisp interpreter is non-reentrant, this is not possible.

> See this: https://github.com/emacs-lsp/lsp-mode/issues/676#issuecomment-476700911
> 
> That means if a native-code thread is to be run in parallel with the UI thread, it can never access an Env. 

Yes, but so what?  You can still do work in the module threads, then
send the accumulated results to emacs from the main thread.

Again, this is all too abstract.  A useful discussion would have many
more details regarding the job that needs to be done and the
bottle-necks that need to be distributed to threads running in
parallel.

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

[HaiJun Zhang]

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

在 2020年3月21日 +0800 PM4:16，Eli Zaretskii <eliz@gnu.org>，写道：
>
> Yes, but so what? You can still do work in the module threads, then
> send the accumulated results to emacs from the main thread.
>

Many users complain the lag of lsp-mode(lsp client for emacs). I’m also suffering from it, while the lsp works much better in vim and VSCode.
There are too many json messages in communication between emacs(lsp client) and lsp server.

In that discussion,  some people want to parse the json messages in a module thread and prepare lisp data for emacs to use. But it is not possible because of the limit.

If json messages are parsed in module thread and saved as c struct data(not lisp data), they have to be translated to lisp data before emacs use. The translation which should be done in emacs thread cost too much cpu, which make the parallel parsing of json messages not very useful.

Is it possible to parse json messages and prepare data struct for pdumper, and translate the data to lisp using pdumper? What about the performanse comparing with the above?


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

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

[Eli Zaretskii]

> Date: Sun, 22 Mar 2020 09:12:23 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org
> 
>  Yes, but so what? You can still do work in the module threads, then
>  send the accumulated results to emacs from the main thread.
> 
> Many users complain the lag of lsp-mode(lsp client for emacs). I’m also suffering from it, while the lsp works
> much better in vim and VSCode.
> There are too many json messages in communication between emacs(lsp client) and lsp server. 
> 
> In that discussion,  some people want to parse the json messages in a module thread and prepare lisp data
> for emacs to use. But it is not possible because of the limit.

Suppose a module thread will be able to parse JSON: what would the
main (a.k.a. "Lisp") thread of Emacs do while the module thread is
working?  Doesn't it need to wait for the parsed data anyhow?

> If json messages are parsed in module thread and saved as c struct data(not lisp data), they have to be
> translated to lisp data before emacs use. The translation which should be done in emacs thread cost too
> much cpu, which make the parallel parsing of json messages not very useful.

You are saying that the translation is costly, but did someone
actually measure that and verify that it's indeed costly?  And if
someone did, where can I see the results in sufficient level of detail
to understand what part(s) of parsing JSON are the bottleneck?

> Is it possible to parse json messages and prepare data struct for pdumper, and translate the data to lisp
> using pdumper? What about the performanse comparing with the above?

I don't think I understand what does pdumper have to do with this
issue.

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

[HaiJun Zhang]

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

在 2020年3月22日 +0800 PM10:32，Eli Zaretskii <eliz@gnu.org>，写道：
>
> Suppose a module thread will be able to parse JSON: what would the
> main (a.k.a. "Lisp") thread of Emacs do while the module thread is
> working? Doesn’t it need to wait for the parsed data anyhow?
>

They don’t known each other. It will be good if module thread can post message to lisp thread. It will be better if module thread can send lisp data within the message to lisp thread.


>
> > If json messages are parsed in module thread and saved as c struct data(not lisp data), they have to be
> > translated to lisp data before emacs use. The translation which should be done in emacs thread cost too
> > much cpu, which make the parallel parsing of json messages not very useful.
>
> You are saying that the translation is costly, but did someone
> actually measure that and verify that it's indeed costly? And if
> someone did, where can I see the results in sufficient level of detail
> to understand what part(s) of parsing JSON are the bottleneck?
>

I have talked with the author of lsp-mode. I think their team have done some work on this.
@yyoncho Can you join the discussion?


> > Is it possible to parse json messages and prepare data struct for pdumper, and translate the data to lisp
> > using pdumper? What about the performanse comparing with the above?
>
> I don't think I understand what does pdumper have to do with this
> issue.

My understanding is that pdumper can serialize and deserialize lisp data. Maybe we can prepare data with its format and let it deserialize them.


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

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

[Eli Zaretskii]

> Date: Tue, 24 Mar 2020 12:22:57 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org, yyoncho@gmail.com
> 
>  Suppose a module thread will be able to parse JSON: what would the
>  main (a.k.a. "Lisp") thread of Emacs do while the module thread is
>  working? Doesn’t it need to wait for the parsed data anyhow?
> 
> They don’t known each other.

I'm not sure I understand the response.  Let me repeat the question:
while the module thread parses JSON, will the main thread wait for it,
or will it do something else?  Can you describe how this would work
using some use case where lsp-mode is used, like for completing on
program symbols?

> It will be good if module thread can post message to lisp thread. It will be
> better if module thread can send lisp data within the message to lisp thread. 

Posting messages is possible by writing to a pipe.  But I don't think
I understand what you mean by "send Lisp data" -- how (in what form)
can Lisp data be sent?

>  I don't think I understand what does pdumper have to do with this
>  issue. 
> 
> My understanding is that pdumper can serialize and deserialize lisp data. Maybe we can prepare data with its
> format and let it deserialize them.

But we already do that: the libjansson library "serializes" the data,
and we then deserialize it in Emacs as we get the data from the
library.  That deserialization is what takes the time you are trying
to make shorter.

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

[Ivan Yonchovski]

HaiJun Zhang writes:

>> > If json messages are parsed in module thread and saved as c struct data(not lisp data), they have to be
>> > translated to lisp data before emacs use. The translation which should be done in emacs thread cost too
>> > much cpu, which make the parallel parsing of json messages not very useful.
>>
>> You are saying that the translation is costly, but did someone
>> actually measure that and verify that it's indeed costly? And if
>> someone did, where can I see the results in sufficient level of detail
>> to understand what part(s) of parsing JSON are the bottleneck?
>>
>
> I have talked with the author of lsp-mode. I think their team have done some work on this.
> @yyoncho Can you join the discussion?

IIRC the bottleneck was the utf conversions (there was similar issue in
native json parsing as well). I havent tested the dynamic module parser
after the latest optimizations. Back then I tested also with the
conversion code disabled and it still was relatively slow compared to
the native json parsing even before the native joson parsing fixes.

HaiJun Zhang, it will be good if you can report the performance issues
you have with lsp-mode. You may follow the guide in the
https://github.com/emacs-lsp/lsp-mode#performance .


Thanks,
Ivan

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

[Eli Zaretskii]

> From: Ivan Yonchovski <yyoncho@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, michael.albinus@gmx.de, 38807@debbugs.gnu.org
> Date: Wed, 25 Mar 2020 18:44:44 +0200
> 
> IIRC the bottleneck was the utf conversions

That should be all but gone now, then.  Right?

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

[Ivan Yonchovski]

Eli Zaretskii writes:

>> From: Ivan Yonchovski <yyoncho@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, michael.albinus@gmx.de, 38807@debbugs.gnu.org
>> Date: Wed, 25 Mar 2020 18:44:44 +0200
>>
>> IIRC the bottleneck was the utf conversions
>
> That should be all but gone now, then.  Right?

Probably yes. I haven't tested it since ATM json parsing is fast enough
or at least we haven't received a bug report about performance. Also,
the dynamic module solution will be slower since it will perform more
work than the native json so there is no point to invest effort into
that.

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

[HaiJun Zhang]

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

在 2020年3月24日 +0800 PM10:40，Eli Zaretskii <eliz@gnu.org>，写道：
>
> I'm not sure I understand the response. Let me repeat the question:
> while the module thread parses JSON, will the main thread wait for it,
> or will it do something else? Can you describe how this would work
> using some use case where lsp-mode is used, like for completing on
> program symbols?
>


1. After user inputs a char, lsp-mode call the module api to setup a completion task. The task has a task id. The lsp-mode saves the task id as the current task and bind a callback function to it. It then returns.
2. The module create a task and adds it to its task queue.
3. The worker thread in the module fetches the task from task queue and executes it. It builds the json-rpc request and sends it to the lsp server. And then it waits for the reply from the lsp server.
4. The worker receives the reply from lsp server. It parses the json message and builds the completion result to a list(in lisp).
5. The worker thread posts a message to emacs. The message includes the task id and the completion result.
6. Emacs receives the message and dispatches it to lsp-mode (by calling a function in lsp-mode). The function checks that it is the result of the completion ask and call the task callback function which will popups a menu to display the completion items.


> > It will be good if module thread can post message to lisp thread. It will be
> > better if module thread can send lisp data within the message to lisp thread.
>
> Posting messages is possible by writing to a pipe. But I don't think
> I understand what you mean by "send Lisp data" -- how (in what form)
> can Lisp data be sent?
>

It  can be the above completion list, a point to a lisp object which can be passed to emacs to for lsp-mode to use.

> > I don't think I understand what does pdumper have to do with this
> > issue.
> >
> > My understanding is that pdumper can serialize and deserialize lisp data. Maybe we can prepare data with its
> > format and let it deserialize them.
>
> But we already do that: the libjansson library "serializes" the data,
> and we then deserialize it in Emacs as we get the data from the
> library. That deserialization is what takes the time you are trying
> to make shorter.

Before lsp-mode, I used completion tools like irony-mode for c/c++ and gocode for golang. They work very smoothly.

Now I have used lsp-mode with emacs-27 or emacs master for several weeks. It doesn’t work as smoothly as the above tools. It lags.

I added some debug messages to lsp-mode and see that there are too many(about 10~30) json messages arrived after I input every char. Emacs has to parse and process all of them on every key pressing.

For the old completion tools, there are only one or two json messages arrived on every key pressing.

Maybe it is the problem of the lsp server. But it is hard to modify them.


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

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

[HaiJun Zhang]

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

在 2020年3月26日 +0800 AM12:44，Ivan Yonchovski <yyoncho@gmail.com>，写道：
>
> HaiJun Zhang writes:
>
> > > > If json messages are parsed in module thread and saved as c struct data(not lisp data), they have to be
> > > > translated to lisp data before emacs use. The translation which should be done in emacs thread cost too
> > > > much cpu, which make the parallel parsing of json messages not very useful.
> > >
> > > You are saying that the translation is costly, but did someone
> > > actually measure that and verify that it's indeed costly? And if
> > > someone did, where can I see the results in sufficient level of detail
> > > to understand what part(s) of parsing JSON are the bottleneck?
> > >
> >
> > I have talked with the author of lsp-mode. I think their team have done some work on this.
> > @yyoncho Can you join the discussion?
>
> IIRC the bottleneck was the utf conversions (there was similar issue in
> native json parsing as well). I havent tested the dynamic module parser
> after the latest optimizations. Back then I tested also with the
> conversion code disabled and it still was relatively slow compared to
> the native json parsing even before the native joson parsing fixes.
>
> HaiJun Zhang, it will be good if you can report the performance issues
> you have with lsp-mode. You may follow the guide in the
> https://github.com/emacs-lsp/lsp-mode#performance .
>
>
> Thanks,
> Ivan


OK. I will do it when I have time.


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

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

[Eli Zaretskii]

> Date: Thu, 26 Mar 2020 21:37:39 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org, yyoncho@gmail.com
> 
>  I'm not sure I understand the response. Let me repeat the question:
>  while the module thread parses JSON, will the main thread wait for it,
>  or will it do something else? Can you describe how this would work
>  using some use case where lsp-mode is used, like for completing on
>  program symbols?
> 
> 1 After user inputs a char, lsp-mode call the module api to setup a completion task. The task has a task id.
>  The lsp-mode saves the task id as the current task and bind a callback function to it. It then returns.
> 2 The module create a task and adds it to its task queue.
> 3 The worker thread in the module fetches the task from task queue and executes it. It builds the json-rpc
>  request and sends it to the lsp server. And then it waits for the reply from the lsp server.
> 4 The worker receives the reply from lsp server. It parses the json message and builds the completion
>  result to a list(in lisp).
> 5 The worker thread posts a message to emacs. The message includes the task id and the completion
>  result.
> 6 Emacs receives the message and dispatches it to lsp-mode (by calling a function in lsp-mode). The
>  function checks that it is the result of the completion ask and call the task callback function which will
>  popups a menu to display the completion items.

If the above describes what happens when the user requests completion,
then I deduce that the user waits for the entire process you described
to finish, because the user cannot continue without seeing the
completion candidates, and those are only available after item 6 above
is done.

Since the user waits for this job to finish anyway, why does it help
to run some of this processing in a separate thread?

>  It will be good if module thread can post message to lisp thread. It will be
>  better if module thread can send lisp data within the message to lisp thread.
> 
>  Posting messages is possible by writing to a pipe. But I don't think
>  I understand what you mean by "send Lisp data" -- how (in what form)
>  can Lisp data be sent?
> 
> It  can be the above completion list, a point to a lisp object which can be passed to emacs to for lsp-mode to
> use. 

A Lisp object that is not stored in the data structures maintained by
alloc.c is not really a Lisp object that has a meaning for Emacs, I
think.

>  My understanding is that pdumper can serialize and deserialize lisp data. Maybe we can prepare
>  data with its
>  format and let it deserialize them.
> 
>  But we already do that: the libjansson library "serializes" the data,
>  and we then deserialize it in Emacs as we get the data from the
>  library. That deserialization is what takes the time you are trying
>  to make shorter. 
> 
> Before lsp-mode, I used completion tools like irony-mode for c/c++ and gocode for golang. They work very
> smoothly.
> 
> Now I have used lsp-mode with emacs-27 or emacs master for several weeks. It doesn’t work as smoothly
> as the above tools. It lags.
> 
> I added some debug messages to lsp-mode and see that there are too many(about 10~30) json messages
> arrived after I input every char. Emacs has to parse and process all of them on every key pressing.
> 
> For the old completion tools, there are only one or two json messages arrived on every key pressing.
> 
> Maybe it is the problem of the lsp server. But it is hard to modify them.

I don't think I understand how this is related to the serialization
issue and the pdumper.

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

[Ivan Yonchovski]

Eli Zaretskii writes:

> Since the user waits for this job to finish anyway, why does it help
> to run some of this processing in a separate thread?

The user might not want to wait for the completion but he/she might want
to continue to type while the parsing is taking place. The effect is
that the typing feels slugish. IME with latest native json parsing this
is no longer the case for lsp-mode.


With my limited understanding of emacs internals I see 2 potential
solutions to allow writing of "lisp workers".

1. Start second(or multiple) elisp interpreter in the emacs process
which has thread local copy of all of the global data(buffers, data
allocation, etc). It may or may not have a gui attached to it. In
addition to that, introduce primitives for moving elisp datastructure
from the background thread to the main UI thread and vice versa
eventually by coping the original structure to avoid bugs.

2. Make the functions that create elisp datastructures threadsafe(or
some sane subset) and expose them to the dynamic modules.

Thanks,
Ivan

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

[HaiJun Zhang]

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

在 2020年3月26日 +0800 PM10:44，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Thu, 26 Mar 2020 21:37:39 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> > Cc: michael.albinus@gmx.de, 38807@debbugs.gnu.org, yyoncho@gmail.com
> >
> > I'm not sure I understand the response. Let me repeat the question:
> > while the module thread parses JSON, will the main thread wait for it,
> > or will it do something else? Can you describe how this would work
> > using some use case where lsp-mode is used, like for completing on
> > program symbols?
> >
> > 1 After user inputs a char, lsp-mode call the module api to setup a completion task. The task has a task id.
> > The lsp-mode saves the task id as the current task and bind a callback function to it. It then returns.
> > 2 The module create a task and adds it to its task queue.
> > 3 The worker thread in the module fetches the task from task queue and executes it. It builds the json-rpc
> > request and sends it to the lsp server. And then it waits for the reply from the lsp server.
> > 4 The worker receives the reply from lsp server. It parses the json message and builds the completion
> > result to a list(in lisp).
> > 5 The worker thread posts a message to emacs. The message includes the task id and the completion
> > result.
> > 6 Emacs receives the message and dispatches it to lsp-mode (by calling a function in lsp-mode). The
> > function checks that it is the result of the completion ask and call the task callback function which will
> > popups a menu to display the completion items.
>
> If the above describes what happens when the user requests completion,
> then I deduce that the user waits for the entire process you described
> to finish, because the user cannot continue without seeing the
> completion candidates, and those are only available after item 6 above
> is done.
>

It doesn’t need to wait. When it needs completion, it setup a task with a task id. If the completion result doesn’t arrive before user input next char. It doesn’t display completion menu. And after user input another  char it setup another task with a new task id and the old task id is retired now. Then if the completion result for the old task arrives, it just discards it. It only displays completion menu when the completion result for the current valid task arrives.

Or when lsp add a new completion task to module, the module will know that the old task is cancelled. And it will not send the old completion result to emacs. This will save more power.

> Since the user waits for this job to finish anyway, why does it help
> to run some of this processing in a separate thread?
>
> > It will be good if module thread can post message to lisp thread. It will be
> > better if module thread can send lisp data within the message to lisp thread.
> >
> > Posting messages is possible by writing to a pipe. But I don't think
> > I understand what you mean by "send Lisp data" -- how (in what form)
> > can Lisp data be sent?
> >
> > It can be the above completion list, a point to a lisp object which can be passed to emacs to for lsp-mode to
> > use.
>
> A Lisp object that is not stored in the data structures maintained by
> alloc.c is not really a Lisp object that has a meaning for Emacs, I
> think.
>

It will be great if emacs support this.

> > My understanding is that pdumper can serialize and deserialize lisp data. Maybe we can prepare
> > data with its
> > format and let it deserialize them.
> >
> > But we already do that: the libjansson library "serializes" the data,
> > and we then deserialize it in Emacs as we get the data from the
> > library. That deserialization is what takes the time you are trying
> > to make shorter.
> >
> > Before lsp-mode, I used completion tools like irony-mode for c/c++ and gocode for golang. They work very
> > smoothly.
> >
> > Now I have used lsp-mode with emacs-27 or emacs master for several weeks. It doesn’t work as smoothly
> > as the above tools. It lags.
> >
> > I added some debug messages to lsp-mode and see that there are too many(about 10~30) json messages
> > arrived after I input every char. Emacs has to parse and process all of them on every key pressing.
> >
> > For the old completion tools, there are only one or two json messages arrived on every key pressing.
> >
> > Maybe it is the problem of the lsp server. But it is hard to modify them.
>
> I don't think I understand how this is related to the serialization
> issue and the pdumper.

Because the most of the above json messages is empty diagnostic messages. I think lsp-mode will do nothing with them except parsing them. I need profiling it.

Many people says that lsp in vim works smoothly. I don’t know if it supports same features with lsp in emacs. I will try it and compare them.


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

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

[HaiJun Zhang]

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

在 2020年3月27日 +0800 AM2:15，Ivan Yonchovski <yyoncho@gmail.com>，写道：
>
> Eli Zaretskii writes:
>
> > Since the user waits for this job to finish anyway, why does it help
> > to run some of this processing in a separate thread?
>
> The user might not want to wait for the completion but he/she might want
> to continue to type while the parsing is taking place. The effect is
> that the typing feels slugish. IME with latest native json parsing this
> is no longer the case for lsp-mode.
>
>
> With my limited understanding of emacs internals I see 2 potential
> solutions to allow writing of "lisp workers".
>
> 1. Start second(or multiple) elisp interpreter in the emacs process
> which has thread local copy of all of the global data(buffers, data
> allocation, etc). It may or may not have a gui attached to it. In
> addition to that, introduce primitives for moving elisp datastructure
> from the background thread to the main UI thread and vice versa
> eventually by coping the original structure to avoid bugs.
>

I’d like not expose any global data to them. Even the data allocation can be standalone. Then they pass lisp object by coping as you said.

> 2. Make the functions that create elisp datastructures threadsafe(or
> some sane subset) and expose them to the dynamic modules.
>
> Thanks,
> Ivan

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

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

[Lars Ingebrigtsen]

HaiJun Zhang <netjune@outlook.com> writes:

> I think the web worker is a good design for GUI applications such as
> web browser. The workers do heavy work and provide the results to the
> UI thread. The UI thread only displays the result and responds to user
> input events which makes good user responsiveness.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I think it's an interesting idea, but it's pretty high level, I don't
think there's anything actionable here as a bug report, so I'm closing
it.  (This sort of this is better suited for discussion on emacs-devel.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no