[Top][All Lists]

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

Re: CVS problem with ssh

From: Derek Price
Subject: Re: CVS problem with ssh
Date: Mon, 27 Jun 2005 10:09:16 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Richard M. Stallman wrote:

>    The code currently works by making the assumption that network reads
>    will always return chunks of data small enough to be written to stdout
>    in a single call to fwrite after a single select on fileno (stdout).
>What would make some data too long?  The nmemb argument of fwrite is a
>size_t, and unless fwrite has a bug, it should handle whatever amount
>of data you specify.
>I don't see why a large amount of data would cause a failure.
>Previous messages claimed that it could, but I think I've refuted that
>claim.  Is there a flaw in the argument I gave?

I've simply been describing what I believe is the current race
condition.  Perhaps you misunderstood the status of the current
workaround in CVS (you may be thinking "fix", but I am attempting to
refute that)?  Currently CVS does a single select on the stdout fileno
before dumping as much data as it last received from the network to
stdout via fwrite.  There is *no looping or checking for EAGAIN
returns*, which I believe you advocated but, I am informed by Larry
Jones and Paul Eggert, would likely be unportable to non-GNU systems.

Currently, this workaround appears to prevent the original problem, but
I think it is working because the select usually implies there is more
room for writing to stdout than we have data only because reading from
the network is slower than writing to disk.  The whole point of this
discussion, I thought, was that we could rely on an EAGAIN return from
GNU fwrite and could retry the write with the remaining data when there
was no room?

Since there is no looping going on and any single fwrite of an arbitrary
amount of data > 1 byte should be able to sometimes trigger the EAGAIN
even after a select, I suspect the race condition described above
exists.  On a fast network with a slow disk, the problem should still be
reproducible.  Perhaps this could be verified by piping the CVS stdout &
stderr to netcat across an even slower network or somesuch.  I don't
know and I don't really have the facilities here to test it.

Though it was not what I was arguing in the above thread - I only meant
to point out that, as I understand the problem, the current situation is
not a true fix, I will reiterate that I still agree with Larry and am
loathe to reimplement stdio in CVS.  I would much prefer to be able to
rely on stdio for a situation like this.

I most certainly don't have the time to reimplement it myself at the
moment and even were a complete patch submitted I would still be
reluctant to accept it due to potential maintenance hassles.  I
understand a similar stdio reimplementation happened in Emacs in the
past and the team eventually gave up on it due to unmaintainability.



reply via email to

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