On Sun, Feb 12, 2012 at 15:16, Robert Millan <r...@debian.org> wrote: > El 12 de febrer de 2012 12:42, Niko Tyni <nt...@debian.org> ha escrit: >> [crossposted to the Debian GNU/kFreeBSD development list debian-bsd >> and the Perl 5 development list perl5-porters ] > > Thanks for bringing this up. > >>> This is also 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. > > This is not correct. LinuxThreads is only obsolete on GNU/Linux, but > it is maintained and used on GNU/kFreeBSD because, contrary to what > its name would indicate, it's a reasonably portable pthread library > with few kernel-specific dependencies.
I'll adjust the commit message to mention that. >> 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. > > The version of LinuxThreads used on GNU/kFreeBSD has been patched to > use kFreeBSD (kernel of FreeBSD) thread primitives, and thus future > releases of Debian GNU/kFreeBSD will no longer be affected by this > problem. > > Debian "Squeeze" release *IS* affected, however. It'd be better if > you could wait at least until there's a new release before breaking > compatibility with Squeeze users. With this patch on top this passes tests on my 6.0 kFreeBSD machine: diff --git a/t/op/getpid.t b/t/op/getpid.t index 67a0f90..7688240 100644 --- a/t/op/getpid.t +++ b/t/op/getpid.t @@ -30,7 +30,16 @@ my $ppid2 : shared = 0; new threads( sub { ($pid2, $ppid2) = ($$, getppid()); } ) -> join(); -# If this breaks you're either running under LinuxThreads or your -# system doesn't have POSIX thread semantics. -is($pid, $pid2, 'getpid() in a thread is the same as in the parent'); -is($ppid, $ppid2, 'getppid() in a thread is the same as in the parent'); +# If this breaks you're either running under LinuxThreads (and we +# haven't detected it) or your system doesn't have POSIX thread +# semantics. +if ($^O =~ /^(?:gnukfreebsd|linux)$/ and + (my $linuxthreads = qx[getconf GNU_LIBPTHREAD_VERSION 2>&1]) =~ /linuxthreads/) { + chomp $linuxthreads; + diag "We're running under $^O with linuxthreads <$linuxthreads>"; + isnt($pid, $pid2, "getpid() in a thread is different from the parent on this non-POSIX system"); + isnt($ppid, $ppid2, "getppid() in a thread is different from the parent on this non-POSIX system"); +} else { + is($pid, $pid2, 'getpid() in a thread is the same as in the parent'); + is($ppid, $ppid2, 'getppid() in a thread is the same as in the parent'); +} However the return values of $$ and getppid() in threads on kFreeBSD with linuxthreads will of course be different. I think that's a feature as pointed out in the original commit message. So here's what we can do: 1. We can take this patch as-is with that fix above on top, which means that it'll pass tests everywhere but on Linux 2.4 and kFreeBSD 6.0 $$ and getppid() will reflect the OS's idea, not our POSIX emulation. 2. I could munge it (urghl) so this whole thing tries to detect linuxthreads, and if they're there we try to cache the pid, this means however that on Linux 2.4 users running embedded PerlInterpreter that they fork (with e.g. uWSGI) will run into subtle issues on Linux 2.4 and kFreeBSD 6.0. I think in practice the number of users that'lle be harmed by the caching will outnumber those that are harmed because they're writing multithreaded Perl programs and relying on this particular feature. 3. We can revert the un-caching of $$ and made everyone suffer the edge cases for the sake of linuxthreads. I obviously much prefer #1, and I don't think it would harm kFreeBSD users, what do you think? Has the Debian GNU/kFreeBSD port had many issues due to differences in getpid()/getppid() behavior? Also what does it even mean that threads have pids? Can you kill(1) threads individuall? Send signals to them that aren't sent to the parent process etc? -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacbzzx6vxdwrh65oerzttgguxsrhsdx3dzttpcpgsdtnhc6...@mail.gmail.com