[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54650: Calling accept() with a non-blocking listening socket, returns a non-blocking connected socket, which is incorrect behaviour
The following reply was made to PR kern/54650; it has been noted by GNATS.
From: Jason Thorpe <thorpej%me.com@localhost>
To: Sad Clouds <cryintothebluesky%gmail.com@localhost>
Martin Husemann <martin%duskware.de@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 06:20:26 -0700
> On Oct 27, 2019, at 12:59 AM, Sad Clouds <cryintothebluesky%gmail.com@localhost> =
> 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
>> Where I read "same properties" as including the socket options.
There is a lot less text in the SUSv4 description of accept(2):
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.
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 =
> OpenBSD accept() man page and it is much more clear there:
> "The accept() call extracts the first connection request on the queue =
> 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 =
> sockets to be also non-blocking. But it looks like another portability
> issue we have to deal with on different platforms.=20
Main Index |
Thread Index |