[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 |
Hello!
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
SOCK_CLOEXEC == O_CLOEXEC and SOCK_NONBLOCK == O_NONBLOCK? Or should
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?
Regards,
Thomas
signature.asc
Description: Digital signature
- Prev by Date:
Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
- Next by Date:
Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
- Previous by thread:
Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
- Next by thread:
Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
- Index(es):