[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: Wed, 16 Jan 2019 10:39:45 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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.

Attachment: 0001-doc-lispref-processes.texi-Accepting-Output-Simplify.patch
Description: Text Data

reply via email to

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