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.