[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: some accept-process-output races fixed; Tramp FIXMEs
Date: Mon, 21 Jan 2019 23:09:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]