[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61350: Eglot over Tramp freezes with large project
From: |
Thomas Koch |
Subject: |
bug#61350: Eglot over Tramp freezes with large project |
Date: |
Tue, 28 Feb 2023 19:55:17 +0200 (EET) |
Thank you both for being so constructively engaged in the bug I opened.
I'll give Joao's patch a try tomorrow. (I'm too tired now.) However I don't see
ControlMaster as the root cause at the moment.
My current working theory is:
1. There is some buffer in SSH (or TCP) that gets filled by the language server
sending data to eglot.
2. Tramp sends a command over SSH.
3. Tramp sets the JUST-THIS-ONE option of accept-process-output to t since
https://debbugs.gnu.org/12145.
4. The response to 2. can not arrive due to the buffer being filled in 1. Tramp
blocks the emacs main thread.
I tested my theory by deleting (and thus disabling) the JUST-THIS-ONE argument
in all calls to accept-process-output in tramp.el and tramp-sh.el. Eglot did
not freeze anymore in two tests with two different systems (but the same jdtls
binary on the same Debian version). In one test however I saw this in the
message buffer:
[jsonrpc] (warning) Invalid JSON: (control character 0xd <callback> 1 381 381)
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///home/thk/git/yacy_search_server/source/net/yacy/htroot/ConfigSearchBox.java","diagnostics":[{"range":{"start":{"line":35,"character":86},"end":{"line":35,"character":94}},"severity":3,"code":"1102","source":"Java","message":"At
least one of the problems in category \u0027unuseContent-Length: 798
{"jsonrpc":"2.0","method":"textDocument/publ
I already sent the above to Michael in an out-of-band thread (thanks for your
patience!).
I have a vague feeling, that Tramp could be improved with a work queue such
that requests to tramp from notification or timer threads get blocked while
another tramp command is still waiting for a reply. Additionally I understand
that Joao has an idea to use markers controlled by Tramp. - I'm sorry that I
can not (yet) contribute with putting both ideas into code.
There are two statements in this bug thread that I don't yet understand and
that might be worth more elaboration. I volunteer as a debugging rubber
duck[1]. However if you both understand each other then never mind:
[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging
Joao: "markers in the process buffer is what is used commonly"
I understand that tramp sends only one command at a time per connection.
Otherwise the reentrant error is thrown. The command result gets written to a
connection-specific buffer. The output is parsed from point-min and the buffer
content deleted after parsing and before sending the next command. So what
should there be improved? Jsonrpc needs its own markers because N messages can
arrive at any given time and the buffer can not be deleted after each message.
Michael: "If another process has consumed the output, even if it is pushed into
the correct buffer, Tramp doesn't know."
What exact scenario should that be? Emacs writes the output (if there's no
filter) in the correct buffer for the process. Tramp might call
accept-process-output unnecessarily because the output is already in the buffer
due to a accept-process-output call of some other code. But in this case Tramp
will find the output there eventually, maybe after having waited until a
timeout. This could be improved by checking for already present output before
calling accept-process-output?
- bug#61350: Eglot over Tramp freezes with large project, (continued)
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/27
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/27
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/27
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/28
- bug#61350: Eglot over Tramp freezes with large project,
Thomas Koch <=
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/28