[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.

From: Thomas Schwinge
Subject: Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
Date: Wed, 10 Dec 2008 17:34:37 +0100
User-agent: Mutt/1.5.11


Roland, thanks for your input!  A few questions remain:

On Wed, Dec 10, 2008 at 12:37:26AM -0800, Roland McGrath wrote:
> accept4.c should define __accept4

Directly accept4 is what it's called in io/accept4.c (without doing weak
aliasing), so I guess we'll (have to) stick with that?

I'll do likewise for dup3, pipe2 and whatever else I find missing.

> CLOEXEC is purely in libc, just pass O_CLOEXEC to _hurd_intern_fd.

Really only pass flags & O_CLOEXEC or rather pass all flags and let
_hurd_intern_fd sort out the ones it's interestied in?  That would make
it future-proof should further flags be added (whichever).

> The whole body should indeed be inside HURD_CRITICAL_BEGIN anyway.
> But that's just for signal safety.  It doesn't have anything to do
> with a window without O_NONBLOCK, since that window would be for
> the port that is not yet installed into an fd.

Understood.  So we use HURD_CRITICAL_BEGIN (and friends) always when
things are supposed to be as atomic as they're in a (Linux) syscall?

Here are the unanswered parts from my earlier email:

About bits/socket.h, where SOCK_CLOEXEC and SOCK_NONBLOCK are to be
defined: we're currently using sysdeps/unix/bsd/bsd4.4/bits/socket.h.
Shall we continue to use this file or instead fork it into a
Hurd-specific one?

Can we be sure (or make sure?) that it will always hold that values of
there be an always-inline function somewhere in glibc to do such
conversion that would always be called before incoming user-specified
socket flags are interpreted as O_* ones?

    __always_inline int
    sanitize_sockflags (int in)
      int out = 0;
      if (in & SOCK_CLOEXEC)
        out |= O_CLOEXEC;
      if (in & SOCK_NONBLOCK)
        out |= O_NONBLOCK;
      /* Others are passed through unfiltered.  */
      out |= in & ~(SOCK_CLOEXEC | SOCK_NONBLOCK);
      return out;

That's not Hurd-specific.  When putting it into include/sys/socket.h we'd
have to include <fcntl.h> in there, which is probably no-go.

sysdeps/unix/sysv/linux/bits/socket.h does define MSG_CMSG_CLOEXEC for
use as a flag to recvmsg to do the obvious for received FDs.  I'll see
about implementing that as well.

Linux now does allow using socket (domain, type | SOCK_*, protocol)
calls.  Shall I change the pf* servers to cope with that (saves one RPC
per use) or shall we filter out these SOCK_* flags (only SOCK_NONBLOCK)
in sysdeps/mach/hurd/socket.c and do manual socket_set_option RPCs?  To
avoid a mischmasch (accept nevertheless needs the extra call) I'd rather
go for the latter one.

Should the generic socket/opensock.c be made to handle SOCK_CLOEXEC like
in sysdeps/unix/sysv/linux/opensock.c?


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]