Technical Linux questions

[Nathan Meyers]

On Sat, Feb 22, 2003 at 04:49:42AM +0000, John Chambers wrote:
> Derek D. Martin writes:
> | I think in general, the more threads look like processes, the less
> | complex the kernel gets, but the less efficient thread switching
> | becomes.  Like everything else, it's a tradeoff.
> 
> Which reminds me of  a  question  I've  never  really  seen
> answered:   How  exactly  do kernel threads differ from the
> result of a vfork() call?

In intent, if nothing else. Threads are intended to allow for multiple
threads of execution in the same process space; vfork is intended to
spawn a child whose only purpose is to immediately exec() a different
executable. One description I found somewhere - I'm not sure how accurate
- is that the parent blocks until the new child exec()s a new executable.

> If a kernel thread gets its own pid, and shares memory with
> the  parent, that's exactly what vfork() did in the systems
> that had it.  Is "kernel thread" just a fancy new name  for
> an old idea?

Threads aren't a fancy new name or new idea. The term "kernel"
distinguishes them from threads that are managed in user space - as many
thread implementations were before kernels got good at supporting them.
(One example, in the Java world, was Sun's "green threads" implementation,
which was usable in environments without any threading facilities of
their own.)

> (One difference seems to be that documentation  on  threads
> is  a  lot more confused and ambiguous, making it difficult
> to determine exactly how they behave.  ;-)

There's a lot of context management needed to make threads work
properly. Given its limited functionality, vfork() doesn't have to
provide such management - that's more than a documentation difference :-).

Nathan Meyers
nmeyers at javalinux.net