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

[Daniel Colascione <dancol@dancol.org>]

On 1/20/19 4:57 AM, Michael Albinus wrote:
> Paul Eggert <eggert@cs.ucla.edu> 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.

In general, timeout arguments that mean "I really want to just poll" 
should be exactly zero.