Subj : Re: process vs. thread ids on linux
To   : comp.programming.threads
From : David Butenhof
Date : Thu Jun 02 2005 06:54 pm

jpknott@gmail.com wrote:
> So, what is going on here?   If the kernel is indeed assigning a new
> pid to each thread, how can I get to that id (since getpid() doesn't
> work).  Why doesn't getpid() work, anyway?    And can I then use these
> pids to send signals directly to a particular thread (which I was under
> the impression was not possible)?

On Linux, threads are "processes" -- or rather, both are instances of 
"clones", the Linux implementation of "variable weight processes".

In LinuxThreads, each thread would return its own unique value when you 
called getpid(). This is fixed in NPTL by REDIRECTING getpid() to a new 
function that returns the "thread group pid" so that all threads in a 
process (or "all Linux processes in a POSIX process") return the same value.

But either way, each process/pid HAS its own pid -- whether or not it 
chooses to use it, because that's how the kernel schedules them.

You can think of this as a sort of "global pthread_t value"; although 
POSIX doesn't require a pthread_t value to be valid outside the process, 
it doesn't prohibit that either. (Though it would be foolish to depend 
on that; and in fact I don't believe that NPTL actually uses the 
thread/process pid as the pthread_t value anyway.)

This seems odd because of the contradictory terminology. But any modern 
OS that supports POSIX threads has some form of "kernel scheduling 
entity", or KSE that can be scheduled as a process, or as a thread 
within a multithreaded process. A "Linux process" is just it's form of KSE.

If you avoid opening the curtain, it doesn't matter whether it's just a 
little man or the great and powerful Oz... right? ;-)

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.