This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Assume that pipe2 is always available
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 13 Apr 2017 20:18:15 +0200
- Subject: Re: [PATCH] Assume that pipe2 is always available
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D4AE87D0C9
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D4AE87D0C9
- References: <20170413153744.A69B2400F200A@oldenburg.str.redhat.com>
I have looked at the NaCl port.
It does not support fork or the exec* family of functions. This means
that the O_CLOEXEC flag is quite meaningless. O_NONBLOCK is still
useful. The races can largely be obscured due to the lack of fork
support. The exception is dup3, where the new descriptor will
temporarily lack the O_CLOEXEC flag, and this flag is actually
observable by a racing thread (because the descriptor is specified by
the caller). But this looks like a minor issue.
In any case, I think it is possible to implement a reasonable emulation
of pipe2 and dup3 in glibc for NaCl (unlike Linux, where kernel support
would be needed). So I would like to proceed with these cleanups even
if we decide not to remove the NaCl port.
Thanks,
Florian