This isn't a Linux difference - it's an AS difference.
On the same machine, 2.3.3 scheduled procs can do [ns_thread getid] and
will get a number that represents a Linux process, but 3.4 will return
a number that does not represent a Linux process, i.e., there is no
corresponding number in the /proc filesystem.
The difference isn't that important - mainly just pointing it out because
it blew up one of our monitoring tools. We read /proc/<pid>/status to
monitor server memory. We need to use [ns_info pid] to get the process
ID with 3.4 rather than [ns_thread getid].
*All* Linux threads are true processes, IMO, with the primary
difference from unthreaded processes being that they share a lot of
attributes of the parent process: address space, file descriptors,
signal crap (maybe/optional), ... They are processes in that they are
separately scheduled entities as far as Linux is concerned, and do not
need to cooperatively schedule themselves. Depends on your definition
of process I guess.
Jim
>
> > Is every thread a process, or does Linux just implement threads
> > using a process pool (where each process is responsible for N-number
> > of threads, where N=1 could be true).
>
> Linux implements threads as "light weight processes", so they do tend to
> get their own process id (which also mean, I believe, that the number of
> threads is limited by the max number of processes). Not all systems do
> this (solaris for one does not seem to).
>
> They are not true processes, though, although some aspects of their
> behavior are similar. I don't know offhand the differences but I remember
> it being discussed in books like the O'Reilly pthreads book.
>
> ------------------------------------------
> Rusty Brooks : http://www.rustybrooks.org/
> Spewing wisdom from every orifice
> ------------------------------------------
>
