Re: [PATCH 1/2] run-parallel: rename set_nonblocking to set_nonblocking_or_die

Junio C Hamano [off-list ref] writes:

Torsten Bögershausen [off-list ref] writes:

quoted

(Jumping into an old discussion, I may be off topic)

I think this is exactly the latest "I wonder" from Peff, to which I
said "well, perhaps we didn't need nonblock after all from the
beginning".

quoted

And this work regardless if the fd blocking or not, so from that point of view,
the set_nonblocking() is not needed at all.

The major question is, if the poll() works under Windows, (and I
haven't found time to dig further)

;-)

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-<.

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