Further eliminate POSIX-emulation under LinuxThreads

Under POSIX threads the getpid() and getppid() functions return the
same values across multiple threads, i.e. threads don't have their own
PID's. This is not the case under the obsolete LinuxThreads where each
thread has a different PID, so getpid() and getppid() will return
different values across threads.

Ever since the first perl 5.0 we've returned POSIX-consistent
semantics for $$, until v5.14.0-251-g0e21945 when the getpid() cache
was removed. In 5.8.1 Rafael added further explicit POSIX emulation in
perl-5.8.0-133-g4d76a34 [1] by explicitly caching getppid(), so that
multiple threads would always return the same value.

I don't think all this effort to emulate POSIX sematics is worth it. I
think $$ and getppid() are OS-level functions that should always
return the same as their C equivalents. I shouldn't have to use a
module like Linux::Pid to get the OS version of the return values.

This is pretty much a complete non-issue in practice these days,
LinuxThreads was a Linux 2.4 thread implementation that nobody
maintains anymore[2], all modern Linux distros use NPTL threads which
don't suffer from this discrepancy. Debian GNU/kFreeBSD does use
LinuxThreads in the 6.0 release, but they too will be moving away from
it in future releases, and really, nobody uses Debian GNU/kFreeBSD
anyway.

This caching makes it unnecessarily tedious to fork an embedded Perl
interpreter. When someone that constructs an embedded perl interpreter
and forks their application, the fork(2) system call isn't going to
run Perl_pp_fork(), and thus the return value of $$ and getppid()
doesn't reflect the current process. See [3] for a bug in uWSGI
related to this, and Perl::AfterFork on the CPAN for XS code that you
need to run after forking a PerlInterpreter unbeknownst to perl.

We've already been failing the tests in t/op/getpid.t on these Linux
systems that nobody apparently uses, the Debian GNU/kFreeBSD users did
notice and filed #96270, this patch fixes that failure by changing the
tests to test for different behavior under LinuxThreads, I've tested
that this works on my Debian GNU/kFreeBSD 6.0.4 virtual machine.

If this change is found to be unacceptable (i.e. we want to continue
to emulate POSIX thread semantics for the sake of LinuxThreads) we
also need to revert v5.14.0-251-g0e21945, because currently we're only
emulating POSIX semantics for getppid(), not getpid(). But I don't
think we should do that, both v5.14.0-251-g0e21945 and this commit are
awesome.

This commit includes a change to embedvar.h made by "make
regen_headers".

1. http://www.nntp.perl.org/group/perl.perl5.porters/2002/08/msg64603.html
2. http://pauillac.inria.fr/~xleroy/linuxthreads/
3. http://projects.unbit.it/uwsgi/ticket/85

1 files changed, 1 insertions, 7 deletions

diff --git a/hints/linux.sh b/hints/linux.sh
index d0ac9fa9ff..5713fafe81 100644
--- a/hints/linux.sh
+++ b/hints/linux.sh
@@ -365,15 +365,9 @@ fi
 # This script UU/usethreads.cbu will get 'called-back' by Configure
 # after it has prompted the user for whether to use threads.
 cat > UU/usethreads.cbu <<'EOCBU'
-if getconf GNU_LIBPTHREAD_VERSION | grep NPTL >/dev/null 2>/dev/null
-then
-    threadshavepids=""
-else
-    threadshavepids="-DTHREADS_HAVE_PIDS"
-fi
 case "$usethreads" in
 $define|true|[yY]*)
-        ccflags="-D_REENTRANT -D_GNU_SOURCE $threadshavepids $ccflags"
+        ccflags="-D_REENTRANT -D_GNU_SOURCE $ccflags"
         if echo $libswanted | grep -v pthread >/dev/null
         then
             set `echo X "$libswanted "| sed -e 's/ c / pthread c /'`