Re: [PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets

On Nov 24, 2007 12:28 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote: > OK, but maybe for consistency, we might accept the two mechanisms. It's not a question of the kernel interface. The issue with all these extensions is the userlevel interface. Ideally no new userlevel interface is needed. This

Re: [PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets

Ulrich Drepper a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dumazet wrote: 1) Can the fd passing with recvmsg() on AF_UNIX also gets O_CLOEXEC support ? Already there, see MSG_CMSG_CLOEXEC. OK, but maybe for consistency, we might accept the two mechanisms. The one added in

Re: [PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dumazet wrote: > 1) Can the fd passing with recvmsg() on AF_UNIX also gets O_CLOEXEC > support ? Already there, see MSG_CMSG_CLOEXEC. > 2) Why this O_NONBLOCK ability is needed for sockets ? Is it a security > issue, and if yes could you remind

Re: [PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets

Ulrich Drepper a écrit : This patch adds support for setting the O_NONBLOCK flag of the file descriptors returned by socket, socketpair, and accept. Thanks Ulrich for this v5 series. I have two more questions. 1) Can the fd passing with recvmsg() on AF_UNIX also gets O_CLOEXEC support ? (

[PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets

This patch adds support for setting the O_NONBLOCK flag of the file descriptors returned by socket, socketpair, and accept. socket.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) --- linux/net/socket.c +++ linux/net/socket.c @@ -362,7 +362,7 @@ static int sock_alloc_fd