Re: some accept-process-output races fixed; Tramp FIXMEs

[Michael Albinus]

Paul Eggert <address@hidden> writes:

Hi Paul,

> The Tramp code still contains several loops like this:
>
>   (while (or (accept-process-output p 0.1)
>              (process-live-p p)))
>
> that suffer from race conditions. Consider the following sequence of events:
>
> * accept-process-output times out after 0.1 seconds, and returns nil.
> * P generates some data and then exits.
> * process-live-p returns nil.
>
> In this case the loop will exit and lose data. This bug is caused by
> the " 0.1" in that loop. I don’t know why the " 0.1" is there, but if
> the " 0.1" has to be there then I suppose one way to fix the bug would
> be to enhance accept-process-output so that its caller can distinguish
> a timeout from a connection-closed.

IIRC, the timeout is used because accept-process-output could be blocked
otherwise. Tramp has often the need to check whether there is still
output from the process, and the timeout is the only way I know that
accept-process-output returns in finite time.

At least this was the case 15+ years ago, and also supporting XEmacs. If
we could guarantee that (accept-process-output p) returns when either
output has arrived and or the process has finished, I could change the
code. This promise must be kept for all Emacs versions since 24, and for
all platforms, including w32.

Best regards, Michael.