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

[Eric Blake]

On 01/26/2012 07:28 AM, Bruno Haible wrote:
> 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
> 
> Can you please describe a situation with multiple threads where gnulib's
> pipe2() implementation would lead to problems?
> 
>>  I took the line off the existing documentation for the
>>  similar-in-purpose *at() functions.
> 
> The other functions (openat, renameat, etc.) are marked "not multithread-
> safe" because they depend on the 'save-cwd' module. But 'pipe2' doesn't.
> So what's the MT problem you are seeing with lib/pipe2.c?

Thread one calls pipe2(O_CLOEXEC), but gets the gnulib version, which
first calls pipe(), then we context switch.
Thread two calls fork(), and in the child, calls exec()
Thread one then resumes and calls fcntl().  Oops - the application
thought that using pipe2() would be atomic and prevent the child of
thread 2 from seeing the leaked pipe.  That is, the very reason that
pipe2() was invented (atomically setting FD_CLOEXEC on newly-created
fds) cannot be guaranteed by the gnulib replacement.

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

signature.asc
Description: OpenPGP digital signature