[Top][All Lists]

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

Re: CVS problem with ssh

From: Richard M. Stallman
Subject: Re: CVS problem with ssh
Date: Fri, 24 Jun 2005 12:37:00 -0400

    >It's possible that this fix is a full and correct solution.  If the
    >descriptor has room for at least one byte, `write' won't return
    >EAGAIN; it will write at least one byte.  It may write less than the
    >whole buffer that was specified.  If the stdio code handles that case
    >correctly, the results should be correct.

    Are you telling me that the glibc implementation of streams provides a
    buffer with infinite space?

No, that's not what I said.  It seems there is misunderstanding.

      POSIX 1003.1 says fwrite() returns errors
    as fputc().

I don't have a copy I can check.  If this is true, it doesn't directly
conflict with what I said about `write'.  However, it could be
relevant to the question of whether the current code really works.
Let's look at what it implies:

        The fputc() function shall fail if either the STREAM is unbuffered
        or the STREAM's buffer needs to be flushed, and:


            The O_NONBLOCK flag is set for the file descriptor underlying
            /stream/ and the thread would be delayed in the write operation.

If libc operates by calling `write', which will write some of the data,
and then calls `write' again and it fails with EAGAIN, and that causes
`fputc' to fail, everything should work correctly (see my other message).

That text is also consistent with an implementation of `fputc' which
returns EAGAIN without writing any data.  With such an implementation,
the program would busy-wait, because `select' would return immediately
and it would call `fputc' again, which would return EAGAIN again, etc.
That would be wasteful but the output would still be correct.

I think it is unlikely that any libc implementation would behave this
way.  The natural way to implement it is to call `write', which will
write enough to fill up the buffer; then, after `fputc' fails,
`select' will wait.

    Regardless of the fact that this will usually hold true, the algorithm
    still contains a race condition, might not hold true across diverse
    platforms, and is not a true fix.

I do not see the race condition.

reply via email to

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