Re: [PATCH] pipe2: document lack of thread-safety in replacement

[Eric Wong]

Eric Blake <address@hidden> 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 <address@hidden>
> > ---
> >  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