Further eliminate POSIX-emulation under LinuxThreadsavar/remove-linuxthreads-pid-caching

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.

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 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 box.

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().

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, 0 insertions, 3 deletions

diff --git a/util.c b/util.c
index fbe0f8da77..1ff591353c 100644
--- a/util.c
+++ b/util.c
@@ -2857,9 +2857,6 @@ Perl_my_popen(pTHX_ const char *cmd, const char *mode)
       default, binary, low-level mode; see PerlIOBuf_open(). */
    PerlLIO_setmode((*mode == 'r'), O_BINARY);
 #endif 
-#ifdef THREADS_HAVE_PIDS
-	PL_ppid = (IV)getppid();
-#endif
 	PL_forkprocess = 0;
 #ifdef PERL_USES_PL_PIDSTATUS
 	hv_clear(PL_pidstatus);	/* we have no children */