Re: CVS problem with ssh

[Derek Price]

Richard M. Stallman wrote:

>      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.
>
>What do you mean by "unportable"?  As far as I can see, that change
>could not do any harm on any system.  If it fixes the problem on GNU
>systems, that's an important improvement, so why not do it?
>  
>

It might not do any additional harm.  I won't claim to understand the
issue completely, but I was told that there might be data loss since
EAGAIN may not mean what it is supposed to on some systems.  I suppose
that we would be no worse off than we are now.

Paul Eggert was also claiming that a successful select on STDOUT_FILENO
wouldn't necessarily imply a successful write of even a single byte to
the stdout stream (in a loop context, so I don't believe he was
referring to any potential race condition), though I know of no set of
conditions where that would happen.

>It sounds like you can rely on stdio on a GNU system.  
>

In the loop we are avoiding, perhaps.  In its current context, obviously
not, which is where I wanted to be able to rely on it.

>If other
>systems don't handle this reliably, maybe that is their fault.  You
>could report bugs in fwrite if they fail to write the data and don't
>return EAGAIN.
>  
>

Again, we could install loops around fwrite in handle_m, handle_e,
handle_mbinary, and handle_mt and transfer most of the data coming
across from the server correctly to stdout/stderr, but this still
wouldn't handle other client output.  That would require a complete
stdio wrapper, replacing all our calls to printf, fprintf, fflush, etc. 
This would be serious work and not easily maintainable.  It really seems
the much simpler solution for ssh to play nice with the standard file
descriptors.

Regards,

Derek