[Top][All Lists]

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

Re: Lost process output in pipe between Emacs and CVS

From: Ian Lance Taylor
Subject: Re: Lost process output in pipe between Emacs and CVS
Date: 08 Jul 2002 19:16:19 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Richard Stallman <rms@gnu.org> writes:

>     I don't know what the general fix is.  It makes sense for CVS to leave
>     file descriptor 2 untouched when executing the CVS_RSH program, so
>     that any errors from that program will appear on stderr.
> Can CVS be made to cope with EAGAIN on stdout?
> That would fix the problem, right?  Even if did something stupid
> like sleep for a second and try again, that would still fix the bug.

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.

Perhaps the emacs CVS mode can avoid the problem by not dup-ing
descriptor 1 to descriptor 2.  That won't help other users, though.

I suppose that before CVS does a write to stdout or stderr due to data
read from the child process, it could check the blocking status of the
file descriptor, and temporarily block it if necessary.  It would be
tedious to check every time, but it would probably be safe to assume
that if the descriptor were ever blocking, it would remain blocking


reply via email to

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