Allow to buffer more input messages #2879
Comments
|
See https://docs.rs/crossbeam-channel/0.4.0/crossbeam_channel/fn.bounded.html I just tried adjusting the channel, which resulted in much higher latency for lsp requests. I suspect, that the problem is here: https://github.com/rust-analyzer/rust-analyzer/blob/ad10d0c8b91e1db600adb1f323cd71a9ab8dbaac/crates/ra_lsp_server/src/main_loop.rs#L182 When multiple messages are in the queue from the stdio thread to the main loop, it will select over the stdio message channel, and a bunch of other stuff. The select! may not be fair, and randomly select bad things, when multiple recv() are ready at once. I think the 0 sized stdio channel is probably a design choice. I suggest patching the lsp-mode in emacs, to push requests to the ra_lsp_server in a non blocking fashion. You can write to a pipe in non blocking mode with (O_NONBLOCK) flag set on the file descriptor. No idea how that works in emacs. |
|
Yeah, I have read the documentation. The latency sounds bad. The problem with Emacs, AFAIU they are do the best what they in the plugin with async in Emacs. This "async" interface of Emacs just blocks when the pipe is full. |
|
I have a busy week right now, so I haven't really looked into this yet,
but, in general, rust-analyzer is architectured in such a way that it
drains the messages stream as fast as possible. In particular, the main
loop does not block on anything else, all real work is done in the
background.
*If* we observe that the main loop gets stuck, that means we have a bug,
where something blocks the main loop while it shouldn't.
…On Wed, 22 Jan 2020 at 10:35, Bastian Köcher ***@***.***> wrote:
Yeah, I have read the documentation. The latency sounds bad.
The problem with Emacs, AFAIU they are do the best what they in the plugin
with async in Emacs. This "async" interface of Emacs just blocks when the
pipe is full.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2879>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANB3MYCUTJX46ZJ5WITCO3Q7AHPZANCNFSM4KJC5XMA>
.
|
|
Yeah no problem @matklad :) |
@bkchr Could you try to take a backtrace of the running ra_lsp_server? E.g. with I think there is a currently a known issue, where all threads get stuck somewhere, and only one thread is working at 100%: #2812 |
|
@ruabmbua still with my old version: |
|
All the other threads are waiting for some condition. |
|
Yeah looks pretty similar. |
|
As this also comes from the |
|
Yeah, if there is no thread currently waiting in the mainloop, then nothing will happen. On which OS are you? -> Also, I suggest moving this discussion to #2812 |
|
I'm on Linux. Yeah I close this issue. |
Include the current Crate name in the measureme output name See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/measureme.20flamegraph.20panics/near/356367013 cc `@andjo403` Currently, attempting to use `MIRIFLAGS=-Zmiri-measureme=miri cargo miri test` on a crate with multiple test targets (which is very common) will produce a corrupted measureme output file, because the various interpreter processes will stomp each other's output. This change does not entirely prevent this, but the various test targets seem to always have different crate names, so if nothing else this will make the broken measureme files much harder to encounter by accident, while also making it clear what they are all for.
Include the current Crate name in the measureme output name See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/measureme.20flamegraph.20panics/near/356367013 cc `@andjo403` Currently, attempting to use `MIRIFLAGS=-Zmiri-measureme=miri cargo miri test` on a crate with multiple test targets (which is very common) will produce a corrupted measureme output file, because the various interpreter processes will stomp each other's output. This change does not entirely prevent this, but the various test targets seem to always have different crate names, so if nothing else this will make the broken measureme files much harder to encounter by accident, while also making it clear what they are all for.
Not sure about the title, but let me explain what I mean. I'm often experiencing some freezes of Emacs when using
rust-analzyer. When Emacs freezes,rust-analyzeris normally under high load. I suspected thatlsp-modeis not doing some in async fashion, but AFAIK the do the best. They useprocess-send-stringin lisp which can block when the process pipe is full. I suspected thatrust-analyzeris not cleaning upstdinfast enough, when the process is under high load. So, I dig a little bit intorust-analyzerand found this: https://github.com/rust-analyzer/lsp-server/blob/master/src/stdio.rs#L19The
stdinthread blocks until the message was consumed. Do you think we could at least add some buffer, maybe 100 messages? Could also be configurable. Or does lsp support throwing away messages and notifying the client?The text was updated successfully, but these errors were encountered: