[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:
[EAGAIN]
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.
- CVS problem with ssh, Richard M. Stallman, 2005/06/22
- Re: CVS problem with ssh, Frank Hemer, 2005/06/22
- Re: CVS problem with ssh, Larry Jones, 2005/06/22
- Re: CVS problem with ssh, Derek Price, 2005/06/22
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/23
- Re: CVS problem with ssh, Derek Price, 2005/06/23
- Re: CVS problem with ssh,
Richard M. Stallman <=
- Re: CVS problem with ssh, Derek Price, 2005/06/24
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/25
- Re: CVS problem with ssh, Derek Price, 2005/06/27
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/28
- Re: CVS problem with ssh, Derek Price, 2005/06/28
- Re: CVS problem with ssh, Richard M. Stallman, 2005/06/29
- Re: CVS problem with ssh, Derek Price, 2005/06/29
- Re: CVS problem with ssh, Derek Price, 2005/06/29