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

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 27, 2019, at 12:59 AM, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
> 
> 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
>> 

There is a lot less text in the SUSv4 description of accept(2):

<quote>
The accept() function shall extract the first connection on the queue of pending connections, create a new socket with the same socket type protocol and address family as the specified socket, and allocate a new file descriptor for that socket. The file descriptor shall be allocated as described in File Descriptor Allocation.
</quote>

It does not explicitly allow the historic BSD behavior, nor does it explicitly forbid it.

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

-- thorpej