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
