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

> From ac334523b4a7ba23a5198ad60a97456055ffbfbd Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
> Date: Wed, 15 Mar 2023 20:02:43 +0000
> Subject: [PATCH 3/4] A simpler fix for bug#61350, a small tweak Michael's
>  original idea.
>
> * lisp/net/tramp.el (tramp-accept-process-output): Accept process
> from related processes.
> ---
>  lisp/net/tramp.el | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
> index 47173b95bea..a7406a9d80e 100644
> --- a/lisp/net/tramp.el
> +++ b/lisp/net/tramp.el
> @@ -5800,6 +5800,11 @@ tramp-accept-process-output
>  This is needed in order to hide `last-coding-system-used', which is set
>  for process communication also.
>  If the user quits via `C-g', it is propagated up to `tramp-file-name-handler'."
> +  (when-let (((process-get proc 'shared-socket))
> +	     (v (process-get proc 'vector)))
> +    (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, without even documenting this.

And even if this behaviour was documented, I don't think it is what
Elisp programmers want. It's hard to be 100% sure that calling a simple
functions such as 'expand-file-name' will work as expected in presence
of arbitrary timers or process filters. Remember that Emacs can have
pretty hardcore timers or process filters: In M-x shell, the process
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'.

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.

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
on the heap without calling any process filters or timers. Subsequent
calls to 'accept-process-output', or more accurately,
wait_reading_process_output, would then first call the process filters
on the previously saved output from the heap.

This solution would probably be quite complex to implement, but having
thought about this problem for two days, I haven't come to any other
idea. If there aren't any objections or better ideas, I could start
working on it after I finally receive copyright paperwork.

>    (with-current-buffer (process-buffer proc)
>      (let ((inhibit-read-only t)
>  	  last-coding-system-used
> -- 
> 2.39.2
>