Re: Lost process output in pipe between Emacs and CVS

[Ian Lance Taylor]

Richard Stallman <rms@gnu.org> writes:

>     CVS uses stdio, and stdio doesn't work very well with non-blocking
>     file descriptors.  CVS can detect the error easily enough, but at that
>     point stdio has already thrown away the buffer full of data, and CVS
>     hasn't recorded it anywhere.  While in principle CVS could switch to
>     not use stdio, that would be a fairly substantial change.
> 
> Many programs use stdio, and these programs ought to work when run
> under ssh.  This suggests that ssh and stdio are responsible for the
> problem, and one or the other of them should be fixed.

When programs are run under ssh, they will work correctly.

This is a different case.  CVS is invoking ssh in a child process in a
way which causes them to share file descriptor 2.  ssh is then
unblocking file descriptor 2 in a way which CVS does not expect.  This
type of problem can only happen with programs which invoke ssh.

> It would be best to fix stdio, I think.  What platform is CVS running
> on when it fails?  Does stdio in GNU libc handle non-blocking file
> descriptors properly?  If not, we can fix it.

The failure which I see occurs on GNU/Linux using GNU libc 2.2.5.
Specifically, in new_do_write() in libio/fileops.c, if the call to
_IO_SYSWRITE() (i.e., write()) fails for any reason, including EAGAIN,
the contents of the output buffer are discarded.

Ian