GNU bug report logs - #61350
Eglot over Tramp freezes with large project

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: João Távora <joaotavora <at> gmail.com>
Cc: Thomas Koch <thomas <at> koch.ro>, 61350 <at> debbugs.gnu.org
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Tue, 07 Mar 2023 14:52:30 +0100

João Távora <joaotavora <at> gmail.com> writes:

Hi João,

>> Thanks Michael! What is the advantage of this patch over just removing the JUST-THIS-ONE argument?
>> In both cases tramp is triggering accept-process-output for processes it does not own.
>
> Yes, I also ask myself that question.  Though here, Tramp
> has "shared" ownership of them, sort of, so it's more
> conservative when compared to the current mechanics.

Indeed.

> Michael, your patch goes in the right direction but AFAIR
> a single accept-process-output is not guaranteed to bring
> into the process filter all the buffered data.
>
> In "40.9.4 Accepting Output from Processes":
>
>      [In accept-process-output, ] If PROCESS is
>      non-‘nil’ then this function does not return until some output has
>                                                  [^^^^^^^^^^^^^^^^^]
>      been received from PROCESS or PROCESS has closed the connection.
>
>
> Note "some", not "all".  So while less common, I think the hang
> can still happen.
>
> So maybe you meant:
>
>    (while (accept-process-output p 0 nil t))
>
> as suggested in that section?

That was my first idea as well. But tramp-accept-process-output itself is
called in a loop, so there's no difference in practice[1].

Pls give my patch testing, in order to see whether Tramp still blocks.

> João

Best regards, Michael.

[1]: In theory, there's no difference between theory and practice. In
practice, there is. :-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.