[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [PATCH] pipe2: document lack of thread-safety in replacement
Date: Thu, 26 Jan 2012 07:32:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]