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

[Paul Eggert]

Michael Albinus wrote:
> >    (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.

Why does it matter how long accept-process-output takes, when the call is in 
that loop? Even if accept-process-output returns in 0.1 seconds, the loop will 
just call it again if the process is live. And if the process is dead, 
accept-process-output cannot block.