On Wed, Nov 04, 2015 at 10:19:43PM -0800, Junio C Hamano wrote: > Having read your message, I notice these disturbing passages in my > copy of manual pages. > > poll(2) has > > BUGS > See the discussion of spurious readiness notifications under > the BUGS section of select(2). > > and then select(2) has > > Under Linux, select() may report a socket file descriptor as > "ready for read‐ ing", while nevertheless a subsequent read > blocks. This could for example happen when data has arrived > but upon examination has wrong checksum and is discarded. > There may be other circumstances in which a file descriptor > is spuriously reported as ready. Thus it may be safer to use > O_NONBLOCK on sock‐ ets that should not block. > > The world is not all Linux, so there may be systems that we do not > have to worry about the bug described here, but there still are some > Linux systems in use in the world, so we cannot assume the bug > described above will not matter, either. > > So I am not convinced that set_nonblocking() is unnecessary X-<. Yes, I've heard of this bug, and I wouldn't be surprised if it is present on many systems. But notice that it is talking about sockets, whereas here I think we are dealing only with pipes. Pipes generally have much simpler and more predictable behavior, and their behaviors are more closely mandated by POSIX. Of course that's all hearsay, and I can't quite you chapter and verse of POSIX (as if that would be enough, anyway) to prove it. But personally, I would be comfortable dropping the non-blocking bits completely from Stefan's series and adding them back in later if anybody can actually find a real-world example that doesn't conform. Of course, simply omitting the O_NONBLOCK bits on Windows would also work if we can guarantee the Windows behavior. It means we're carrying around extra code that may or may not be doing anything useful, but it's not _that_ much code. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html