Re: Thread and process dentifiers (CPU affinity, kill)

Lennart Sorensen
2005-05-20T16:53:14Z

On Fri, May 20, 2005 at 04:51:10PM +0200, Olivier Croquette wrote:
> From the beginning we are talking about the present GNU/Linux systems,
> which do already use NTPL in standard. NPTL is no future standard, it is
> present standard.

Hmm, I just noticed the page I found about NPTL had 2005 date one place
and 2002 in another. Yeah that is what people are using already.

Most current i386 systems do NOT use NPTL yet by default since it only
works on 2.6 kernels, and even then probably only if glibc was compiled
that way.

> This means basicly that 50% of your assertions (like the above) are
> wrong, and your conclusions "suffer" from that :)
>
> The point is that if you make a ps on a decent Linux based system, you
> will *NOT* see one process for each thread. Nor they do appear in /proc.
>
> This means there are *NOT* userland processes.
>
> And therefore, you shall *NOT* be able to reference them as such where a
> process ID is required.

Hmm, I just ran a pthread program and every thread shows up as a process
in ps. Of course that is on a system with a 2.4 kernel compatible
glibc, so that is probably not a valid test. Running on 2.6.11 on an
amd64 with glibc compiled for 2.6 kernels only, I only see one pid for
the multithreaded program.

Doing kill on the threadid on the amd64 does return ESRCH.

Make sure your test is on a 2.6 kernel system with glibc compiled to
only use nptl (so not 2.4 kernel compatible at all). It appears to work
as you want it to now.

Len Sorensen