Subj : Re: process vs. thread ids on linux
To   : comp.programming.threads
From : bluejack
Date : Thu Jun 02 2005 01:25 pm

jpknott@gmail.com wrote:
> I've stumbled across something that violates some of my basic notions
> about posix threads and process ids... Hopefully somebody will be able
> to set me straight.
>
> This is on a Redhat ES box, by the way, running a 2.4.21 kernel build.

Kernels prior to 2.6 (actually 2.5.?, although the 2.5 series is a
development-only series) did not completely and correctly implement
Posix threads, and this is one of the symptoms. There are others.

There are two thread libraries now: LinuxThreads (which you are using)
and NPTL (Native Posix Thread Library). NPTL is the default on 2.6
kernels, and RedHat offers a patch for 2.4 kernels, but it is not an
easy patch to apply, or so I understand.

NPTL will offer the correct system view on a multi-threaded process.

If you are just curious, there is plenty of documentation on why
LinuxThreads works the way it does available on the web. If it's
actually a problem for you, I would recommend upgrading your kernel.

> If the kernel is indeed assigning a new pid to each thread, how can I get to that id (since getpid() doesn't work).

>From within the application, you cannot guarantee it. You could parse
the pid table looking for the pid/app combo that has a parent pid of
'1' -- but that's pretty ugly.

> Why doesn't getpid() work, anyway?

For the reason you suppose: that each thread is in some senses a
distinct process from the perspective of the kernel, although sharing
resources with the others. Until kernel 2.6, thread libraries went to
great lengths to support Posix standards despite the fact that the
kernel did not offer sufficient support for multi-threaded processes.
2.6 is probably not the final word on that, either, but the integration
with NPTL does mean that things like getpid() work correctly.

> And can I then use these
> pids to send signals directly to a particular thread (which I was under
> the impression was not possible)?

You can, but it may not work the way you expect, although since you
shouldn't be able to at all, your expectations really ought to be
undefined :). This is the other major symptom of LinuxThreads'
non-compliance. LinuxThreads and signals mix about as well as cats and
mice. There are many problems of which thread gets which signal and why
that -- thanks to Ulrich Drepper and Ingo Molnar, among others -- NPTL
resolves completely.

-bluejack

.