Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 15:16, Robert Millan <rmh@debian.org> wrote:
> El 12 de febrer de 2012 12:42, Niko Tyni <ntyni@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?
Reply to: