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

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On 1/16/19 5:25 AM, Stefan Monnier wrote:
 > So how can the code tell when it has read all the data?

The code keeps calling accept-process-output until it gets nil.

Now that I think about it, if you just want all the data you needn’t 
call process-live-p. I installed the attached doc patch accordingly.

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.

[-- Attachment #2: 0001-doc-lispref-processes.texi-Accepting-Output-Simplify.patch --]
[-- Type: text/x-patch, Size: 1176 bytes --]

From b76e90d242e9ee0a733fc9d4b6e280eb6892a6d0 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 16 Jan 2019 10:31:21 -0800
Subject: [PATCH] * doc/lispref/processes.texi (Accepting Output): Simplify.

---
 doc/lispref/processes.texi | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index afda8aede8..fd6686e882 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -1870,13 +1870,13 @@ Accepting Output
 @end example
 
 @noindent
-will often work, it has a race condition and can miss some output if
-@code{process-live-p} returns @code{nil} while the connection still
-contains data.  Better is to write the loop like this:
+will often read all output from @var{process}, it has a race condition
+and can miss some output if @code{process-live-p} returns @code{nil}
+while the connection still contains data.  Better is to write the loop
+like this:
 
 @example
-(while (or (accept-process-output process)
-           (process-live-p process)))
+(while (accept-process-output process))
 @end example
 
 @node Processes and Threads
-- 
2.20.1