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

[Eric Blake]

On 01/26/2012 12:26 PM, Eric Wong wrote:
> 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.

The same as we've done for other flags (for example, we've implemented
O_NONBLOCK for mingw).  Basically, if we detect at configuration time
that the system didn't have a flag, then we define an unused bit for the
flag and also define a witness that gnulib owns the bit; then in our
rpl_accept4 function, that witness means that we must strip the bit
before calling the underlying function, as well as do the touch-up work.
 If the OS later defines the flags, we're still okay, whether or not the
OS flag matches our bit definition or not - either you
reconfigure/recompile the app (and pick up the OS definition), or you
continue to pick up the gnulib headers (and get the gnulib bit which
never gets propagated to the OS).

> 
> Maybe new functions taking gnulib-specific flags will have to be
> created...

To some extent, that's what we're already doing - gnulib wires
everything through its own replacements, then makes the headers hide the
fact that replacements are in use so that the rest of the code can use
the normal signatures, as long as they are careful about the caveats
such as no atomic FD_CLOEXEC.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature