Re: kern/54650: Calling accept() with a non-blocking listening socket, returns a non-blocking connected socket, which is incorrect behaviour

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

The following reply was made to PR kern/54650; it has been noted by GNATS.

From: Sad Clouds <cryintothebluesky%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Martin Husemann <martin%duskware.de@localhost>, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54650: Calling accept() with a non-blocking listening
 socket, returns a non-blocking connected socket, which is incorrect
 behaviour
Date: Sun, 27 Oct 2019 07:59:47 +0000

 On Sun, 27 Oct 2019 07:30:02 +0000 (UTC)
 Martin Husemann <martin%duskware.de@localhost> wrote:
 
 >  I think it is also documented in accept(4):
 >  
 >  	... creates a new socket with the same
 >       properties of s and allocates a new file descriptor for the
 > socket. 
 >  Where I read "same properties" as including the socket options.
 >  
 >  Martin
 >  
 
 OK, if that is the case, then please close this bug. Just had a look at
 OpenBSD accept() man page and it is much more clear there:
 
 "The accept() call extracts the first connection request on the queue of
 pending connections, creates a new socket with the same non-blocking
 I/O mode as s, and allocates a new file descriptor for the socket with
 the close-on-exec flag clear."
 
 The way Linux behaves makes more sense to me, just because the
 listening socket is non-blocking, does not mean I want all the accepted
 sockets to be also non-blocking. But it looks like another portability
 issue we have to deal with on different platforms.