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.