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.