Why does start_new_thread() create an extra process under Linux?

[Jon Perez]

Heiko Wundram wrote:

> NPTL (Native Posix Threads Library), the "next-generation" threads library for 
> Linux, handles threads "correctly" in the sense that they are just one 
> process with separate execution frames but shared memory. 

Does this the fact that NPTL threads are 'just one process' mean they
are not created using clone()?  Are NPTL threads not scheduled by
the kernel?

If so, then how come NTPL is described as a 1:1 model which afaik
means 1 application thread is mapped to exactly 1 'kernel' scheduled thread
(or lightweight process if you will) which, again afaik, can only be created
via a clone() call (albeit with different flags) and nothing else.

If NTPL threads are scheduled by NPTL code as opposed to kernel code and are
all mapped onto one process started by one clone() call, wouldn't that make it M:1?


 > What the op was probably seeing was output from an NPTL patched ps, which
 > always shows the threads that are running (not only when asked for it).

Note that my glibc is not NTPL-enabled, it is the stock 2.3.2 used
in Slackware 10 (although the procps-3.2.1 it uses may already be NPTL-ready),
so this would not seem to be the explanation.

If you start the sample program in my original message and it hasn't launched
a thread yet, ps will only show one running process.  The moment it calls
start_new_thread() however, two new processes show up in ps (so that makes
three total)!  Once this newly started thread dies, only one process gets removed,
so there will still be two processes running and that's what's puzzling me.

Same thing applies if you start N number of threads.  Seems there's always
one extra thread lying around after you call start_new_thread().