This message follows up on a bug-cvs thread which can be viewed at:
http://groups.google.com/groups?th=e4df2fdc1f4f4950

> Date: Thu, 25 Jul 2002 12:07:16 -0600 (MDT)
> From: Richard Stallman <[EMAIL PROTECTED]>

> If all stdio output functions handle EAGAIN by sleeping for a short
> time and trying again, most user programs will be happy with the
> results.

This would contradict POSIX 1003.1-2001, which requires that fputc
must fail with EAGAIN in this situation, and that printf etc. must
operate as if by calling fputc.  I expect that there are some programs
that rely on this behavior.  So, if we need better support for stdio
to nonblocking file descriptors, I think it should be added as an
extension, not as an incompatible change.

In this case, though, I'd rather modify CVS to use a portable solution
as suggested below.  This will let CVS work now, even on older glibc
implementations, as well as on non-glibc implementations.


> Do you see another approach that really solves the problem?

You were on the right track in
http://mail.gnu.org/pipermail/bug-cvs/2002-July/009014.html
when you wrote:

> how about making CVS pipe the output through `cat' when
> it invokes a subprocess?  That should be easy.

I would improve on this suggestion as follows.  CVS should
automatically create a "cat"-like process when it is about to invoke
$CVS_RSH, if it detects that the problem might occur.  That is, if the
CVS client detects that stderr and stdout point to the same file, and
that the O_NONBLOCK flag might make a difference with that file (i.e.,
that the file is not a regular file), then the CVS client should
create an extra process to read bytes from $CVS_RSH's stderr and write
bytes to stderr.  That way, there will be no problem if $CVS_RSH sets
the O_NONBLOCK option on $CVS_RSH's stderr.

This "cat"-like process need not invoke the "cat" command -- it can
just read from one file descriptor and write to the other, without
execing any program.

It may sound inefficient to have an extra "cat"-like process, but it
doesn't cost much in practice.  For example, GNU tar sometimes creates
a "cat"-like process when it invokes "gzip" as a subcommand, since GNU
tar needs to reblock the output when writing to tape devices.  This
works fine and almost nobody notices the overhead.  And it's only 50
or 100 lines of source code in GNU tar, so it's not a major
maintenance problem either.

http://mail.gnu.org/pipermail/bug-cvs/2002-July/009175.html
suggests that Derek Robert Price was working on a solution along these
lines.  I think this is a good idea.

I see also that Larry Jones objected in
http://mail.gnu.org/pipermail/bug-cvs/2002-July/009176.html
that Price's solution would be "unnecessary overhead in the vast
majority of cases", but if CVS limits the solution to just the cases
described above, there won't be much overhead in practice.
And anyway, it's better for CVS to not lose data, even if there is a
bit more overhead in doing so.

_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs

Reply via email to