>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.
_______________________________________________
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs
