GNU bug report logs - #62194
30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: miha <at> kamnitnik.top
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 62194 <at> debbugs.gnu.org
Subject: bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29
Date: Thu, 16 Mar 2023 21:57:22 +0000

  On Thu, Mar 16, 2023 at 9:14 PM <miha <at> kamnitnik.top> wrote:
>
> João Távora <joaotavora <at> gmail.com> writes:

> > +    (dolist (p (delq proc (process-list)))
> > +      (when (tramp-file-name-equal-p v (process-get p 'vector))
> > +     (while (accept-process-output p 0)))))
>
> I think that accept-process-output with JUST-THIS-ONE=nil is dangerous
> here. We are now allowing 'file-exists-p', 'expand-file-name' and all
> other functions listed in 'tramp-sh-file-name-handler-alist' to call any
> timer or process filter,

That's exactly what we want.  We _don't_ want to stop other
output to be inhibited from going into the filter.  We want
to let other processes slurp their input as often as possible.

The reason it hung with JUST-THIS-ONE=t is precisely the inverse
reason that it hangs without this hunk (say, in emacs-29).  One
process (say tprocess) is holding its input and jprocess can't read
it because it comes from a shared underlying SSH buffer and that
buffer is likely full (until tprocess empties it a little bit).

At the moment, it is the best we have, both theoretically and
experimentally.

> without even documenting this.

This is the most normal usage of accept-process-output.
Look at all the Emacs code base.  Basically, only Tramp uses
JUST-THIS-ONE.  It's JUST-THIS-ONE who is the aberration.
None  of the process-heavy SLIME, SLY, CIDER IDEs use it.

You can read the manual about JUST-THIS-ONE.  It's in A-O-P.

> filter may call 'read-passwd', entering a recursive edit, in which the
> user can kill any buffer or even a process. Or with midnight-mode
> enabled, a timer kills buffers older than 3 days. I consider these "the
> problem of timing errors that usually plague parallel programming", to
> quote '(elisp) Output from Processes'.

Sorry, I don't immediately see the problem.  I can't prove that there
isn't one :-) that's near impossible.  Normally what is done
is for the problem to be demonstrated with some experiment.

> I'm not saying that my proposal with SIGWINCH is flawless and I agree
> that its unacceptable. I'm just saying that we shouldn't be quite
> satisfied with this solution yet, though it should be fine for some
> time.

I'm not satisfied with it myself.  This is very slow (not that it matters
much).  But is also all around ugly.  The more correct solution is IMHO,
described in bug#61350.  But it will take time to see if it fits into
Tramp (I think it does) but most importantly how (that's the hard bit,
Tramp is a lot of code)

> What I was thinking was perhaps to introduce a function called
> 'accumulate-process-output' which would be similar to
> 'accept-process-output', except that it would only save process output

You can propose this in emacs-devel, but if you permit me to
be slightly immodest, I've been coding with
accept-process-output + filters for almost 15 years and I've never
had the need for this.  I normally want timers and other processes
to run, I don't want to stop the world.

João

Previous Next

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