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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 5, 2015, 06:19 UTC
Message-ID: <xmqq8u6d7ytc.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqfv0l7z2r.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 15 quoted lines

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> (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".
>
>> 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-<.