bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Bruno Haible
Subject: Re: [PATCH] pipe2: document lack of thread-safety in replacement
Date: Thu, 26 Jan 2012 18:07:45 +0100
User-agent: KMail/4.7.4 (Linux/3.1.0-1.2-desktop; KDE/4.7.4; x86_64; ; )

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.
  2) IIRC, in some past POSIX version fork() was declared incompatible with
     threads (or was is exec()?).

Are you OK with this doc adjustment?


--- doc/glibc-functions/accept4.texi.orig       Thu Jan 26 18:00:01 2012
+++ 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.
 @end itemize
 
 Portability problems not fixed by Gnulib:
--- doc/glibc-functions/pipe2.texi.orig Thu Jan 26 18:00:02 2012
+++ doc/glibc-functions/pipe2.texi      Thu Jan 26 17:59:26 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.
 @end itemize
 
 Portability problems not fixed by Gnulib:




reply via email to

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