[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: Daniel Colascione
Subject: Re: some accept-process-output races fixed; Tramp FIXMEs
Date: Mon, 21 Jan 2019 18:02:22 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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

reply via email to

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