From: Eli Zaretskii <eliz@gnu.org>
To: HaiJun Zhang <netjune@outlook.com>
Cc: 38807@debbugs.gnu.org, michael.albinus@gmx.de, yyoncho@gmail.com
Subject: bug#38807: [Feature request]: Support lisp workers like web workers.
Date: Thu, 26 Mar 2020 16:44:50 +0200 [thread overview]
Message-ID: <837dz79nvh.fsf@gnu.org> (raw)
In-Reply-To: <PS1PR03MB3606A0A1BDB6AEA35777A7E0B7CF0@PS1PR03MB3606.apcprd03.prod.outlook.com> (message from HaiJun Zhang on Thu, 26 Mar 2020 21:37:39 +0800)
> 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.
next prev parent reply other threads:[~2020-03-26 14:44 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aade4dc9-4992-4751-9706-9802389ff732@Spark>
2019-12-30 5:27 ` bug#38807: [Feature request]: Support lisp workers like web workers HaiJun Zhang
2019-12-30 15:23 ` Eli Zaretskii
2019-12-30 15:40 ` Dmitry Gutov
2019-12-30 16:26 ` Eli Zaretskii
2020-01-01 3:20 ` HaiJun Zhang
2020-01-01 3:37 ` Eli Zaretskii
2020-01-01 3:57 ` HaiJun Zhang
[not found] ` <39f1e59e-08db-4862-98db-c31c3bcbab06@Spark>
2020-01-01 4:02 ` HaiJun Zhang
2020-01-01 15:32 ` Eli Zaretskii
2020-01-03 2:05 ` HaiJun Zhang
2020-01-03 13:38 ` arthur miller
2020-01-04 5:59 ` HaiJun Zhang
2020-01-04 8:11 ` HaiJun Zhang
2020-01-04 9:07 ` Eli Zaretskii
2020-01-04 9:10 ` HaiJun Zhang
2020-01-01 3:06 ` HaiJun Zhang
2019-12-30 18:31 ` Michael Albinus
2019-12-30 19:19 ` Eli Zaretskii
2019-12-30 19:22 ` Eli Zaretskii
2019-12-31 0:40 ` HaiJun Zhang
2019-12-31 1:39 ` arthur miller
2020-01-01 3:47 ` HaiJun Zhang
2020-01-01 16:23 ` Eli Zaretskii
2020-01-03 3:45 ` HaiJun Zhang
2020-01-03 6:06 ` Eli Zaretskii
2020-01-04 5:47 ` HaiJun Zhang
2019-12-31 16:35 ` Eli Zaretskii
2020-01-01 2:59 ` HaiJun Zhang
2020-01-01 16:21 ` Eli Zaretskii
2020-01-03 3:18 ` HaiJun Zhang
2020-01-03 6:02 ` Eli Zaretskii
2020-01-04 5:26 ` HaiJun Zhang
2020-01-04 9:00 ` Eli Zaretskii
2020-03-21 2:24 ` HaiJun Zhang
2020-03-21 8:16 ` Eli Zaretskii
2020-03-22 1:12 ` HaiJun Zhang
2020-03-22 14:32 ` Eli Zaretskii
2020-03-24 4:22 ` HaiJun Zhang
2020-03-24 14:40 ` Eli Zaretskii
2020-03-26 13:37 ` HaiJun Zhang
2020-03-26 14:44 ` Eli Zaretskii [this message]
2020-03-26 18:14 ` Ivan Yonchovski
2020-03-29 2:41 ` HaiJun Zhang
2020-03-29 2:12 ` HaiJun Zhang
2020-03-25 16:44 ` Ivan Yonchovski
2020-03-25 17:05 ` Eli Zaretskii
2020-03-25 17:21 ` Ivan Yonchovski
2020-03-26 13:49 ` HaiJun Zhang
2020-01-04 5:55 ` HaiJun Zhang
2020-01-03 3:34 ` HaiJun Zhang
2020-01-03 14:10 ` arthur miller
2020-01-04 6:41 ` HaiJun Zhang
2020-01-01 3:16 ` HaiJun Zhang
2020-01-01 9:14 ` Michael Albinus
2020-01-03 2:52 ` HaiJun Zhang
2020-01-03 5:59 ` Eli Zaretskii
2020-01-04 5:19 ` HaiJun Zhang
2020-01-04 8:59 ` Eli Zaretskii
2020-01-04 9:33 ` HaiJun Zhang
2020-01-04 9:51 ` Eli Zaretskii
2020-01-06 5:08 ` HaiJun Zhang
2020-01-06 16:07 ` Eli Zaretskii
2020-01-01 14:52 ` arthur miller
2020-01-03 1:49 ` HaiJun Zhang
2020-01-03 13:35 ` arthur miller
2020-01-03 14:26 ` Eli Zaretskii
2020-01-03 15:14 ` arthur miller
2020-01-03 14:19 ` arthur miller
2020-01-03 14:39 ` Eli Zaretskii
2022-04-30 12:32 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837dz79nvh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=38807@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
--cc=netjune@outlook.com \
--cc=yyoncho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.