Eric Blake <ebl...@redhat.com> wrote: > On 01/25/2012 06:09 PM, Eric Wong wrote: > > As the replacement cannot be made thread-safe, we need to > > document this to prevent users from having a false sense > > of safety. > > > > * doc/glibc-functions/pipe2.texi (pipe2): mention lack of thread-safety > > > > Signed-off-by: Eric Wong <normalper...@yhbt.net> > > --- > > I took the line off the existing documentation for the > > similar-in-purpose *at() functions. > > We need the same for accept4() and other places where we have non-atomic > replacements for FD_CLOEXEC (and someday, I need to get around to > implementing open(O_CLOEXEC), which would also be non-atomic).
I was thinking of having the doc update to accept4() being a separate patch, since gnulib doesn't implement/expose SOCK_CLOEXEC/SOCK_NONBLOCK, either. I can't think of a safe way to implement SOCK_CLOEXEC/SOCK_NONBLOCK/O_CLOEXEC as-is in gnulib and have it be forward-compatible. If we expose the flags in public headers, the OS authors can eventually add support for these things and the native OS flags may be incompatible with what gnulib uses. Maybe new functions taking gnulib-specific flags will have to be created... For cmogstored[1], I chose to ignore *CLOEXEC if I can't get it atomically, and instead manually set FD_CLOEXEC on every (fd >=3) after-forking (fortunately forking is infrequent). > I'm pushing this instead. Thanks. [1] - http://bogomips.org/cmogstored/README it's a new, multi-threading server that forks/execs sometimes
