Junio C Hamano <[email protected]> writes:
> Torsten Bögershausen <[email protected]> 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-<.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
