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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
