[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 10:31:46 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/26/2012 10:07 AM, Bruno Haible wrote:
> Eric Blake wrote:
>> 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()
> Right, this is why pipe2 should better be atomic.
> But this goes beyond of what is normally understood by multithread-safety:
> it affects only programs which use threads *and* fork child processes.
>   1) There are programs (like 'sort' or 'msgmerge') which use threads but
>      no child processes.

True - at which point pipe2() is great for syntactic sugar.

>   2) IIRC, in some past POSIX version fork() was declared incompatible with
>      threads (or was is exec()?).

Actually, the current version of POSIX requires fork() to be
thread-safe, but glibc's implementation is not thread-safe [1], and the
_next_ version of POSIX will be recommending posix_spawn() and a new
_Fork() as the only thread-safe functions [2] (where _Fork() is like
fork() except that pthread_atfork() can't interfere).  Which is kind of
sad - the whole reason pthread_atfork() was introduced was to attempt to
make fork() thread-safe; but in the process of introducing it,
pthread_atfork() became the reason why fork() is not threadsafe.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=4737
[2] http://austingroupbugs.net/view.php?id=62

> +++ doc/glibc-functions/accept4.texi  Thu Jan 26 17:59:28 2012
> @@ -10,7 +10,8 @@
>  This function is missing on many non-glibc platforms:
>  MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, 
> HP-UX 11,
>  IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin 1.7.1, mingw, MSVC 9, 
> Interix 3.5, BeOS.
> -But the replacement function is not atomic in multi-threaded programs.
> +But the replacement function is not atomic; this matters in multi-threaded
> +programs that spawn child processes.

I like it.  That's a definite improvement and accurate characterization
of the issue.

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]