This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: O_CLOEXEC and SOCK_CLOEXEC
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Cc: Thomas Schwinge <tschwinge at gnu dot org>, samuel dot thibault at ens-lyon dot org
- Date: Thu, 8 Oct 2015 10:45:38 -0700 (PDT)
- Subject: Re: O_CLOEXEC and SOCK_CLOEXEC
- Authentication-results: sourceware.org; auth=none
- References: <56152F14 dot 5050606 at redhat dot com> <20151007200432 dot B6B732C39DF at topped-with-meat dot com> <56160B1B dot 5050801 at redhat dot com>
> On 10/07/2015 10:04 PM, Roland McGrath wrote:
> > NaCl defines them but doesn't actually support them.
> > But it doesn't actually support FD_CLOEXEC either.
> > So you can consider NaCl to "support" O_CLOEXEC.
> >
> > On the Hurd, these are implemented entirely in libc. So if any part of the
> > support is missing, it can be fixed in libc.
>
> What about SOCK_NONBLOCK? There is fallback code which looks at the
> SOCK_CLOEXEC flag, but actually uses SOCK_NONBLOCK.
The Hurd's bits/socket.h does define SOCK_NONBLOCK. But AFAICT it's not
actually implemented. Unlike CLOEXEC, this is not something that would be
implemented in libc. I don't see signs in the Hurd server code that it's
implemented there. But Thomas and/or Samuel would have better information.