[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61350: Eglot over Tramp freezes with large project
From: |
Michael Albinus |
Subject: |
bug#61350: Eglot over Tramp freezes with large project |
Date: |
Sat, 25 Feb 2023 15:27:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
João Távora <joaotavora@gmail.com> writes:
Hi João,
>> You don't call jsonrpc--notification-dispatcher anymore in the
>> process filter directly. But calling it by a timer has the same effect:
>> The process filter (accepting output) is still active,
>
> What exactly do you mean by "still active" and what process are you
> referring to? Jsonrpc's or Tramp?
Your timer is called immediately, while you're still in
jsonrpc--process-filter I believe.
>> > Since jsonrpc always accepts output from *all* running processes, there
>> > could be (and is!) the constellation, that process output has been read
>> > already, and Tramp didn't get it, waiting for the output forever.
>
> I could understand if we were talking C and read() here, but the process
> output of other processes read by jsonrpc's call to accept-process-output
> surely must have run through some filter function, it wasn't just lost
> AFAIK. You've probably seen this trick a mililon times, but markers
> in the process buffer is what is used commonly.
It wasn't lost. The process output was retrieved and placed into the
Tramp buffer, w/o Tramp's interaction.
Tramp doesn't use a process filter for its own connections. The problem
is rather, that Tramp must know where the output to be parsed starts in
the buffer.
If another process has consumed the output, even if it is pushed into
the correct buffer, Tramp doesn't know.
>> Again, I still believe we need a general solution in Tramp, using threads.
>
> I don't understand what is conceptually impossible (or very hard) to
> achieve with evented IO like we have in Emacs.
I've tried different patches, mainly in tramp-accept-process-output. It
improves the situation a little bit, but not reliably. Sometimes the
test works, sometimes it blocks. And even if it doesn't block, a while
later we run into the "Forbidden reentrant call of Tramp" error.
Honestly, I still don't understand really what's up. Let's see whether
adding threads to Tramp helps.
Best regards, Michael.
- 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/23
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/23
- bug#61350: Eglot over Tramp freezes with large project, Thomas Koch, 2023/02/23
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/23
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/24
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/24
- bug#61350: Eglot over Tramp freezes with large project,
Michael Albinus <=
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/25
- bug#61350: Eglot over Tramp freezes with large project, Thomas Koch, 2023/02/26
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/26
- bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/26
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/26
- bug#61350: Eglot over Tramp freezes with large project, João Távora, 2023/02/26
- 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/27
bug#61350: Eglot over Tramp freezes with large project, Michael Albinus, 2023/02/27