[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: Sad Clouds <cryintothebluesky%gmail.com@localhost>
Cc: Martin Husemann <martin%duskware.de@localhost>, kern-bug-people%netbsd.org@localhost,
Subject: Re: kern/54650: Calling accept() with a non-blocking listening
socket, returns a non-blocking connected socket, which is incorrect
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
> Where I read "same properties" as including the socket options.
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.
Main Index |
Thread Index |