bug#61350: Eglot over Tramp freezes with large project

[João Távora]

On Fri, Feb 24, 2023 at 5:19 PM Michael Albinus <michael.albinus@gmx.de> wrote:

> sorry for the delay, I have been out of order the last days :-(

No problem.  Hope you're feeling better!

> As said above, same result: eglot hangs. Your patch doesn't change the
> game.

Sorry to hear about that, I thought it was problem related to processes
inside processes.

> 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?

> and the called
> function in the timer still uses file-truename, which tries to read
> output from the Tramp process.

This part I can understand.  But I don't understand this that you wrote
in the original message:

> > 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.

> 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.