Re: stdio and non-blocking descriptors (patch for glibc manual)

[Richard Stallman]

    +See @ref{File Position} and @ref{File Status Flags}.  For example, if
    +one process makes the file descriptor non-blocking, the other process
    +should not use @code{fprintf} on the corresponding stream.  @xref{Error
    +Recovery}.

This is not strong enough.  If one process makes *any* standard output
file descriptor non-blocking, neither process should use stdio for *any*
standard output descriptor.

I don't think the problem is limited to fprintf.  There will be
problems with fputc too, unless the code takes special care and checks
its return code.  This should recommend, as your last change does, that
people avoid stdio altogether in such cases.

      Hence if there is any
    +possibility that a process might make one of its file descriptors
    +non-blocking, all processes that share that file descriptor should avoid
    +using the corresponding stream.

It's not just the corresponding stream that you can't use.  You have
to assume that any "two" inherited descriptors might in fact be the
same one.

      For example, if the command @samp{ssh
    +foo bar} makes its @code{stdout} non-blocking, any program that invokes
    address@hidden foo bar} as a child process with a shared @code{stdout} 
stream
    +must avoid using @code{fprintf} on that stream.

The actual problem case is that cvs uses fprintf on stderr.
But it turned out that descriptors 1 and 2 were the same descriptor,
so when the child ssh made its stdout non-blocking, that affected
CVS's stderr as well.