[PATCH] Further eliminate POSIX-emulation under LinuxThreads

[Ævar Arnfjörð Bjarmason]

On Sun, Feb 12, 2012 at 15:16, Robert Millan <rmh at debian.org> wrote:
> El 12 de febrer de 2012 12:42, Niko Tyni <ntyni at 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?