[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: |
Wed, 22 Jun 2005 15:44:17 -0400 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Richard M. Stallman wrote:
>Couldn't this be fixed easily by changing cvs to handle EAGAIN
>in a simple way when outputting to stdout? If it just sleeps for a second
>and tries again, that ought to fix the problem.
>
>
Mark Baushke installed Frank Hemer's partial work-around for this
problem some time ago. This should have been released with CVS 1.11.18
& 1.12.10:
2004-08-17 Mark D. Baushke <mdb@cvshome.org>
* sanity.sh (sshstdio): Fix comment typo plus gratuitous
reformatting.
* client.c (handle_m): Workaround to deal with stdio getting put
into non-blocking via redirection of stderr and interaction with
ssh on some platforms. On those boxes, stdio can put stdout
unexpectedly into non-blocking mode which may lead to fwrite() or
fflush() failing with EAGAIN, but cvs not checking for the error.
(Patch suggested by Frank Hemer <frank@hemer.org>.)
* client.c (handle_e): Similar fix for stderr.
* sanity.sh (sshstdio): New test for non-blocking stdio via ssh.
This fix selects on the file descriptor associated with the stream
before writing to the stream via stdio, which is probably wrong on
several levels, as Paul Eggert pointed out in this discussion:
<http://lists.gnu.org/archive/html/bug-gnulib/2004-09/msg00010.html>.
This is also definitely only a workaround and I suspect won't work for
very large file sizes since the select only guarantees that the
descriptor is ready for a single byte, not an arbitrary amount of data,
though it appears to handle the original test case.
I agree with Larry Jones, that the problem is deeper. It seems to me
that any program writing to stderr or stdout via stdio should have the
reasonable expectation that the stream will remain blocking, or perhaps
remain non-blocking, as the case may be.
If we have to fix anything on the CVS side, I think the only complete
fix (read working in all cases) would be to replace all our stdio calls
with our own buffering writes that handled things regardless of EAGAIN.
Much of the code that would be necessary is already in CVS 1.12.x - it's
used for the network buffers on the server side, but nobody has
submitted the patch to apply it everywhere and, as I said, I agree now
that this change would be wrong so I have not written it myself. The
same would need to be done in any program piping output through ssh,
some of which don't have CVS's infrastructure, and this seems unreasonable.
Regards,
Derek
- CVS problem with ssh, Richard M. Stallman, 2005/06/22
- Re: CVS problem with ssh, Frank Hemer, 2005/06/22
- Re: CVS problem with ssh, Larry Jones, 2005/06/22
- Re: CVS problem with ssh,
Derek Price <=
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/23
- Re: CVS problem with ssh, Derek Price, 2005/06/23
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/24
- Re: CVS problem with ssh, Derek Price, 2005/06/24
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/25
- Re: CVS problem with ssh, Derek Price, 2005/06/27
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/28
- Re: CVS problem with ssh, Derek Price, 2005/06/28