>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 Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs